CHAPTER 4 ■ HOME IS HOME 138 rsync -a code steev@remote-backup-host.com:~/backup/daily I recover them (for testing 8 ) with this: rsync -a steev@remote-backup-host.com:~/backup/daily code The options here perform a recursive update, while maintaining all symlinks, permissions, and user settings and is the most typical in home situations. The manual pages detail other possibilities. rsync does have two problems, however. The first is that it’s available primarily for Unix-oriented platforms. Versions are available for Windows (such as DeltaCopy and the version with Cygwin), but they take a little while to set up and can be tricky. The second issue is that it requires a password to be interactively given in order to log in to the remote site. This is a nuisance and prevents any kind of automatic backup. For a remote site to allow a user to connect without a password, they must first establish an alternative form of trust—in this case, the exchange of public keys. To copy from machine A to machine B, B must have a copy of A’s public key. To copy from machine B to machine A, A must have a copy of B’s public key. In our case, machine A is at home with our files, while B is a remote machine for backup. So, our home machine must generate a key for the user who’ll be doing the copying. ssh-keygen -t rsa which by default can be found in ~/.ssh/id_rsa.pub. This is then copied to the remote machine (perhaps using a password-directed rsync) and appended to the list of authorized keys that the remote user will accept: cat id_rsa.pub >> ~/.ssh/authorized_keys Once this is done, you should be able to rsync without a password: rsync -a bwlimit=100 steev@remote-backup-host.com:~/backup/daily code Note that this limits the bandwidth (with the bwlimit argument) to 100 kilobytes per second so that other applications can make use of the Internet, since rsync and ssh are rather greedy when teamed up together. One potential administration problem that can exist here is for the home user to be refused a connection because the address from which they’re connecting does not match the one used in the key. This can happen when the hostname is something simply like linuxbox1 but appears to the remote machine as netpc-london-isproute-isp.com or something equally unhelpful. The target machine, by comparison, will usually have a fixed name since it must be addressable from the outside world. Since the home machine name might change (at the whim of the ISP), the easiest solution is to reverse all the instructions given here! That is, use the remote server to connect to the home server, generate a key for the remote server only, and reverse the arguments to the rsync command so that the remote server pulls the data from the home machine in order to perform the backup. It is curious to note that it is the direction of the connection that requires the authentication, not the direction of the copy process. 8 All backups are useless unless they’re tested, remember! CHAPTER 4 ■ HOME IS HOME 139 ■ Note The root user cannot, by default, connect through ssh. Although it is possible to override this, it is not recommended, so create a new user, create the ssh key for them, and use their crontab to initiate the daily backup. Although this solves the problems for Linux and MacOS users, there still needs to be a solution for Windows. If you can afford the time, preparing rsync on Windows can be worthwhile. Alternatively, you might want to instill best practices into the family by introducing a manual backup solution that requires them to do something to back up their work. This is one area in which Subversion scores higher, because the workflow encourages this automatically. What can be done instead is to create a writable SMB shared area on the network that is accessible to everyone, and it is their responsibility to add their files to it every night before bed. You can then use rsync to back up this network folder remotely. There are several free and shareware utilities for Windows that provide the copy-based backup necessary for the first step. Of course, everything I’ve said assumes that you’re storing your data at home. In most cases that will be true, but it is now easier than ever to buy space on a remote server (through Amazon’s S3, for example, with a virtual machine), which means you never need to back up. Of course, backups are still being done (by the automated tools and support staff at the server provider), but they’re transparent to you. 9 In the cases of external storage, you would only want to store data that was fairly small in size since streaming a full movie from a remote server would be unwatchable, and having to wait until it had downloaded would be equally annoying and defeat the purpose. These situations are beneficial in some cases because they mean no personal data is ever stored at home. So if a burglar steals your laptop, you haven’t lost the novel you’ve been working on. Some people prefer to protect their private data in public, by using services such as Flickr, Google Docs, and YouTube. The situation is the same as earlier with the exception that, being free services, there are fewer warranties about loss of data. Indeed, Google Mail has a personal storage limit of just over 7GB, which allows you to back up your data by saving them as attachments in your mail account! Or by using gmailfs. There is also the possibility of backing up the physical items in your home, namely, your media. Although the importance in CDs and DVDs is in the packaging, it is possible to save the contents by ripping them (as we covered in Chapter 3) onto external hard disks and placing the drives themselves in storage, either held with friends, with family, or in a professional safe. You could probably arrange a pairing scheme with suitably technical friends who will store your collection of discs in return for you keeping theirs. The same pairing idea works if you both rsync your media to each other during quiet periods of network traffic, such as during the night, for example. 9 As a paranoid geek, I would personally make my own backups periodically, in addition to those made by someone else. CHAPTER 4 ■ HOME IS HOME 140 Hiding Your Home Having a home connected to the Internet provides a way of consuming your media when away from home, remotely configuring your machines, and checking that you did indeed turn the lights off. It also provides great bragging rights! However, having it connected in this is naturally a concern for some. Even with the technical security issues I’ll be covering in Chapter 5, there’s some extra scope for hiding your automated home in much the same way as you’d put a blanket over the valuables in the car when you park it. One way is to set up two domain names for your home machine. The first should be considered the public site, which provides a smoke screen, and may contain a web site and blog featuring your cat! By being the default web site, this will be used whenever the IP address is used alone. (I’ll cover the method when discussing virtual hosts in Chapter 5.) You can then additionally set up a second domain with access to your home automation web pages. You will still secure these pages, naturally, but this is a good first step. Although registering domain names is easy enough, it is not necessarily the best option when dealing with home machines, because your IP might change when a DHCP lease is not renewed at the whim of the ISP, and you’d have to wait another 24 hours for the DNS information to repropagate through the various DNS servers. Although this is unlikely, even if you decide to power down the server every night, better solutions are available by using dynamic DNS. The method assigns an arbitrary subdomain, from a known primary domain, to a given IP. Because subdomains do not need to be propagated by DNS before they can be used, they have a more immediate effect and can be registered for very little money—in most cases, zero. One such service is available from dyndns.org. After registering (also free!), you can create your own subdomain and point it to your home server. This subdomain can extend from one of several primary domains, such as homelinux.net, mine.nu, or dnsalias.com. The T&C requires that you update this record periodically to ensure it’s still active, but this can be done automatically with appropriate routers or through a package such as ddclient. This should be run periodically, either in daemon mode or from crontab, to keep their records up-to-date. The configuration simply requires your login credentials for DynDNS and the subdomain names you want to update. # /etc/ddclient.conf daemon=600 use=web, web=checkip.dyndns.com/, web-skip='IP Address' login=your-username password=your-password protocol=dyndns2 server=members.dyndns.org my.homelinux.net Because this is a DNS record, only the name is registered. It’s still up to you to support the services. But this is what you want, because it allows you to run your own servers for e-mail, the Web, SSH, and so on. You can hide behind more curtains by providing access only through an external proxy—a proxy whose existence and login is known only to you. The first step is to prepare the hosts.allow file with the following: sshd: LOCAL myhidden.privateserver.com CHAPTER 4 ■ HOME IS HOME 141 and add the paranoid inverse to hosts.deny: sshd: ALL As you can guess, when used in combination, this limits all SSH connections to those originating from the local (192.168.x.x) network and those on an external server that might be a colocated server, work machine, or shell account. ■ Note These rules can apply to all protocols, not just SSH, by changing sshd to ALL in the previous examples. This approach is not without risk, however, because should your server become inaccessible for any reason, you will be able to connect to it (and therefore solve the problem) only from the specified machines, which might be difficult if you are on vacation. ■ Note If your private server supports multiple domains, the name that is specified here to sshd must be the canonical one. You can extend this idea by controlling your house through an alternate protocol, such as Simple Object Access Protocol (SOAP), from a remote server, although this does open up two potential points of attack. Adding to Your Home The simplest way to incorporate automation into your home is through wireless—or at the least, automation that uses no new wiring. This second approach covers a surprisingly large amount of ground, including networking through WiFi and Ethernet over Power, appliance control (with X10 over the existing power cables), and media distribution (with TV senders.) But even then, with so many devices occupying the 2.4GHz range, there will be a limit to what is possible and how far it can be expanded. So, naturally, a wired approach will begin to win favor, which will require some drilling of holes and running of cables. In all the advice that follows, remember that you must always plan ahead, thinking about what each room will have in it, what it could have in it next year, and how it will be used. Running cables is a time- consuming process and not something that wants to be repeated, so it’s better to lay too many and have unused sockets than it is to run out when you attempt to plug in a new gadget and find that you first need to buy an expanded unit. Cable is, after all, comparatively cheap when compared to the cost of installation or maintenance. Having two cables is a also useful redundancy measure in all the following examples, if you have the space to include them. CHAPTER 4 ■ HOME IS HOME 142 General Considerations Except in very esoteric cases, Node0 will always be at the center of your HA installation. Even if it is not physically close to the center of the house, all cables should be run into it. This is known as a star configuration. The process of running cables from one location to another is known as pulling cables, since it involves the act of pulling them through one set of holes to another. When you’re adding to an existing home, you will generally need to drill holes in the ceilings and pull cables down through wall-mounted trunking, as shown in Figure 4-1. With self-builds, you may have the opportunity to place the cables inside the walls themselves, making them invisible except for the wall plate beside the skirting board. Of course, if you’re doing some major redecorating, then you might decide it’s worth removing the wall and replastering to make the cabling invisible. Figure 4-1. Trunking to hide the cables and a volute to (try to) hide the join. Whichever approach you take, it’s best to pull all the cables at the same time: audio, Cat5, and coaxial. If necessary, buy four drums of network cable so you can pull multiple Cat5 cables through at the same time. This will save a lot of effort. ■ Note If you are planning a projector in any room, then you will generally need to run cables within the ceiling itself, which involves lifting the floorboards of the room above. When this is likely, do it earlier since you won’t want to do it later and might live without a projector; plus, you can take the opportunity to lay a lot more cables in the same space than you would normally. . CHAPTER 4 ■ HOME IS HOME 138 rsync -a code steev@remote-backup-host.com:~/backup/daily I recover them (for testing 8 ) with this: rsync -a steev@remote-backup-host.com:~/backup/daily. machine A is at home with our files, while B is a remote machine for backup. So, our home machine must generate a key for the user who’ll be doing the copying. ssh-keygen -t rsa which. done, you should be able to rsync without a password: rsync -a bwlimit=100 steev@remote-backup-host.com:~/backup/daily code Note that this limits the bandwidth (with the bwlimit argument) to