Introducing
Your new presentation assistant.
Refine, enhance, and tailor your content, source relevant images, and edit visuals quicker than ever before.
Trending searches
Linux server week 6&7
1
Linux server week 6 & 7
Backups are always trade-offs. Any backup consumes time, money, and effort on an ongoing basis; backups must be monitored, validated, indexed, and stored, and you must continuously purchase new media. Sound expensive? The cost of not having backups is the loss of your critical data. Re-creating the data from scratch costs time and money, and if the cost of doing it all again is greater than the cost associated with backing up, you should be performing backups. At their most basic, backups are nothing more than insurance against financial loss for you or your business.
Your first step in formulating and learning to use an effective backup strategy is to choose the strategy that is right for you. First, you must understand some of the most common (and not so common) causes of data loss so that you are better able to understand the threats your system faces. Then, you need to assess your own system, how it is used and by whom, your available hardware and software resources, and your budget constraints. The following sections look at each of these issues in detail and provide some backup system examples and discuss their use.
Back ups
Why Data Loss Occurs
why dataloss
Files disappear for any number of reasons: They can be lost because the hardware fails and causes data loss; your attention might wander and you accidentally delete or overwrite a file. Some data loss occurs as a result of natural disasters, and other circumstances beyond your control. A tornado, flood, or earthquake could strike, the water pipes could burst, or the building could catch on fire. Your data, as well as the hardware, would likely be destroyed in such a disaster. A disgruntled employee might destroy files or hardware in an attempt at retribution. Equipment can be stolen. And any equipment might fail; all equipment fails at some time—most likely when it is extremely important for it not to fail.
CP command
To make a backup of a configuration file you are about to edit, use the cp command:
matthew@seymour:~$ cp filename filename.original
To restore it, use the following:
matthew@seymour:~$ cp filename.original filename
Now open up your servers and try a cp command.
making back uos
back up needs
By now you have realized that some kind of plan is needed to safeguard your data, and, like most people, you are overwhelmed by the prospect. Entire books, as well as countless articles and white papers, have been written on the subject of backing up and restoring data. What makes the topic so complex is that each solution is truly individual.
Yet, the proper approach to making the decision is very straightforward. You start the process by asking the following:
>What data must be safeguarded?
>How often does the data change?
The answers to these two questions determine how important the data is, determine the volume of the data, and determine the frequency of the backups. This in turn determines the backup medium. Only then can the software be selected to accommodate all these considerations. (You learn about choosing backup software, hardware, and media later in this chapter.)
Available resources are another important consideration when selecting a backup strategy. Backups require time, money, and personnel. Begin your planning activities by determining what limitations you face for all these resources. Then, construct your plan to fit those limitations, or be prepared to justify the need for more resources with a careful assessment of both backup needs and costs.
Many people also fail to consider the element of time when formulating their plan. Some backup devices are faster than others, and some recovery methods are faster than others. You need to consider that when making choices.
To formulate your backup plan, you need to determine the frequency of backups. The necessary frequency of backups should be determined by how quickly the important data on your system changes. On a home system, most files never change, a few change daily, and some change weekly. No elaborate strategy needs to be created to deal with that. A good strategy for home use is to back up (to any kind of removable media) critical data frequently and back up configuration and other files weekly.
At the enterprise level on a larger system with multiple users, a different approach is called for. Some critical data is changing constantly, and it could be expensive to re-create; this typically involves elaborate and expensive solutions. Most of us exist somewhere in between these extremes. Assess your system and its use to determine where you fall in this spectrum.
Backup schemes and hardware can be elaborate or simple, but they all require a workable plan and faithful follow-through. Even the best backup plan is useless if the process is not carried out, data is not verified, and data restoration is not practiced on a regular basis. Whatever backup scheme you choose, be sure to incorporate in it these three principles:
>Have a plan—Design a plan that is right for your needs and have equipment appropriate to the task. This involves assessing all the factors that affect the data you are backing up. We delve into more detail later in the chapter.
>Follow the plan—Faithfully complete each part of your backup strategy and then verify the data stored in the backups. Backups with corrupt data are of no use to anyone. Even backup operations can go wrong.
>Practice your skills—Practice restoring data from your backup systems from time to time, so when disaster strikes, you are ready (and able) to benefit from the strength of your backup plan. (For restoring data, see the section “Using Backup Software.”) Keep in mind that it is entirely possible that the flaws in your backup plan will become apparent only when you try restoring.
You have to create your own best backup plan, but here are some building blocks that go into the foundation of any sound backup program:
> Maintain more than one copy of critical data.
> Label the backups.
> Store the backups in a climate-controlled and secure area.
> Use secure, offsite storage of critical data. Many companies choose bank vaults for their offsite storage, and this is highly recommended.
> Establish a backup policy that makes sense and can be followed religiously. Try to back up your data when the system is consistent (that is, no data is being written), which is usually overnight.
> Keep track of who has access to your backup media and keep the total number of people as low as possible. If you can, allow only trusted personnel near your backups.
> Routinely verify backups and practice restoring data from them.
> Routinely inspect backup media for defects and regularly replace them (after destroying the data on them if it is sensitive).
Now that you are convinced you need backups, you need a strategy. It is difficult to be specific about an ideal strategy because each user or administrator’s strategy will be highly individualized, but here are a few general examples:
>Home user—At home, the user has the Ubuntu installation DVD that takes less than an hour to reinstall, so the time issue is not a major concern. The home user will want to back up any configuration files that have altered, keep an archive of any files that have been downloaded, and keep an archive of any data files created while using any applications. Unless the home user has a special project in which constant backups are useful, a weekly backup is probably adequate. The home user will likely use a consumer-focused online cloud service like Dropbox, an external hard drive, or other removable media for backups.
>Small office—Many small offices tend to use the same strategy as the home user but are more likely to back up critical data daily and use manually changed tape drives. If they have a tape drive with adequate storage, they will likely have a full system backup as well because restoring from the tape is quicker than reinstalling from the CDs. They also might be using a CD-RW or DVD writers for backups. Although they will use scripts to automate backups, most of it is probably done by hand. This category is also moving to online cloud services for backup as technology is becoming more mature and less expensive.
>Small enterprise—Here is where backups begin to require higher-end equipment such as auto-loading tape drives with fully automated backups. Commercial backup software usually makes an introduction at this level, but a skillful system administrator on a budget can use one of the basic applications discussed in this chapter. Backups are highly structured and supervised by a dedicated system administrator. You might have guessed that small enterprises are also moving their backups to online cloud services.
>Large enterprise—These are the most likely setting for the use of expensive, proprietary, and highly automated backup solutions. At this level, data means money, lost data means lost money, and delays in restoring data means money lost as well. These system administrators know that backups are necessary insurance and plan accordingly. Often, these own their own online, distributed cloud systems, with multiple redundant data centers in geographically diverse locations.
Does all this mean that enterprise-level backups are better than those done by a home user? Not at all. The “little guy”, with Ubuntu, can do just as well as the enterprise operation at the expense of investing more time in the process. By examining the higher-end strategies, we can apply useful concepts across the board.
Backup Levels
UNIX uses the concept of backup levels as a shorthand way of referring to how much data is backed up in relation to a previous backup. It works this way:
A level 0 backup is a full backup. The next backup level is 1.
Backups at the other numbered levels will back up everything that has changed since the last backup at that level or a numerically higher level. (The dump command, for example, offers 10 different backup levels.) For example, a level 3 followed by a level 4 generates an incremental backup from the full backup, and a level 4 followed by a level 3 generates a differential backup between the two.
The result is the same.
All files in the /etc directory will be saved to a file named etc.tar. With an impressive array of options (see the man page), tar is quite flexible and powerful in combination with shell scripts. With the -z option, it can even create and restore gzip compressed archives, and the -j option works with bzipped files.
The tar tool, the bewhiskered old man of archiving utilities, is installed by default. It is an excellent tool for saving entire directories full of files. For example, here is the command used to back up the /etc directory:
matthew@seymour:~$ sudo tar cvf etc.tar /etc
Here, the options use tar to create an archive, be verbose in the message output, and use the filename etc.tar as the archive name for the contents of the directory /etc.
Alternatively, if the output of tar is sent to the standard output and redirected to a file, the command appears as follows:
matthew@seymour:~$ sudo tar cv /etc > etc.tar
Basic back up tool
Full back ups with tar
matthew@seymour:~$ sudo find / -newer name_of_last_backup_file ! –type d -print \
tar czT - backup_file_name_or_device_name
Here, the T - option gets the filenames from a buffer (where the - is the shorthand name for the buffer).
The tar command can back up to a raw device (one with no file system) and to a formatted partition. For example
matthew@seymour:~$ sudo tar cvzf /dev/hdd /boot /etc /home
backs up those directories to device /dev/hdd (not /dev/hda1, but to the unformatted device itself).
The tar command can also back up over multiple floppy disks:
matthew@seymour:~$ sudo tar czvMf /dev/fd0 /home
This backs up the contents of /home and spreads the file out over multiple floppies, prompting you with this message:
Prepare volume #2 for '/dev/fd0' and hit return:
Creating Full and Incremental Backups with tar
If you want to create a full backup, the following creates a bzip2 compressed tarball (the j option) of the entire system:
matthew@seymour:~$ sudo tar cjvf fullbackup.tar.bz2 /
To perform an incremental backup, you must locate all the files that have been changed since the last backup. For simplicity, assume that you do incremental backups on a daily basis. To locate the files, use the find command:
matthew@seymour:~$ sudo find / -newer name_of_last_backup_file ! -a –type f –print
When run alone, find generates a list of files system-wide and prints it to the screen. The ! -a -type eliminates everything but regular files from the list; otherwise, the entire directory is sent to tar even if the contents were not all changed.
Pipe the output of our find command to tar as follows:
Restoring Files from an Archive with tar
The xp option in tar restores the files from a backup and preserves the file attributes, as well, and tar creates any subdirectories it needs. Be careful when using this option because the backups might have been created with either relative or absolute paths. You should use the tvf option with tar to list the files in the archive before extracting them so that you know where they will be placed.
For example, to restore a tar archive compressed with bzip2, use the following:
matthew@seymour:~$ sudo tar xjvf ubuntutest.tar.bz2
To list the contents of a tar archive compressed with bzip2, use this:
matthew@seymour:~$ sudo tar tjvf ubuntutest.tar.bz2
tar: Record size = 8 blocks
drwxr-xr-x matthew/matthew 0 2013-07-08 14:58 other/
-rwxr-xr-x matthew/matthew 1856 2013-04-29 14:37 other/matthew helmke public.asc
-rwxr-xr-x matthew/matthew 170 2013-05-28 18:11 backup.sh
-rwxr-xr-x matthew/matthew 1593 2013-10-11 10:38 backup method
Note that because the pathnames do not start with a backslash, they are relative pathnames and will install in your current working directory. If they were absolute pathnames, they would install exactly where the paths state.
The contents of the tar file (held for us temporarily in the buffer, which is named -) are then piped to the second expression, which extracts the files to the target directory. In shell programming (refer to Chapter 14, “Automating Tasks and Shell Scripting”), enclosing an expression in parentheses causes it to operate in a subshell and be executed first.
First you change to the target directory, and then
> x—Extract files from a tar archive.
> p—Preserve permissions.
> f—The filename will be -, the temporary buffer that holds the files archived with tar.
Copying Files Using tar
One choice for copying files into another location is to use the tar command; you just create a tar file that is piped to tar to be uncompressed in the new location. To accomplish this, first change to the source directory. Then the entire command resembles this:
matthew@seymour:~$ tar -cvf files (cd target_directory ; tar -xpf)
In this command, files are the filenames you want to include; use * to include the entire current directory.
Here is how this command works: You have already changed to the source directory and executed tar with the cvf arguments that tell tar to
> c—Create an archive.
> v—Verbose; lists the files processed so you can see that it is working.
> f—The filename of the archive will be what follows. (In this case, it is -.)
The following tar commands can be useful for creating file copies for backup purposes:
> l—Stay in the local file system (so that you do not include remote volumes).
> atime-preserve—Do not change access times on files, even though you are accessing them now (to preserve the old access information for archival purposes).
Sending back ups
Compressing, Encrypting, and Sending tar Streams
The file copy techniques using the tar command in the previous section can also be used to quickly and securely copy a directory structure across a LAN or the Internet (using the ssh command). One way to make use of these techniques is to use the following command line to first compress the contents of a designated directory and then decompress the compressed and encrypted archive stream into a designated directory on a remote host:
matthew@seymour:~$ tar -cvzf data_folder ssh remote_host '( cd ~/mybackup_dir; tar -xvzf )'
The tar command is used to create, list, and compress the files in the directory named data_folder. The output is piped through the ssh (Secure Shell) command and sent to the remote computer named remote_host. On the remote computer, the stream is then extracted and saved in the directory named /mybackup_dir. You are prompted for a password to send the stream.
The cp command can also be used to quickly replicate directories and retain permissions by using the -avR command-line options. Using these options preserves file and directory permissions, gives verbose output, and recursively copies and re-creates subdirectories. You can also create a log of the backup during the backup by redirecting the standard output like this:
matthew@seymour:~$ sudo cp -avR directory_to_backup destination_vol_or_dir 1 > /root/backup_log.txt
or
matthew@seymour:~$ sudo cp -avR ubuntu /test2 1 > /root/backup_log.txt
This example makes an exact copy of the directory named /ubuntu on the volume named /test2 and saves a backup report named backup_log.txt under /root.
Copying Files Using cp
To copy files, we could use the cp command. The general format of the command when used for simple copying is as follows:
matthew@seymour:~$ cp -a source_directory target_directory
The -a argument is the same as giving -dpR, which would be
> -d—Preserves symbolic links (by not dereferencing them) and copies the files that they point to instead of copying the links.
> -p—Preserves all file attributes if possible. (File ownership might interfere.)
> -R—Copies directories recursively.
Copying Files Using mc
The Midnight Commander (available in the Universe repository, under the package mc; see Chapter 9, “Managing Software,” for how to enable the Universe and Multiverse repositories) is a command-line file manager that is useful for copying, moving, and archiving files and directories. The Midnight Commander has a look and feel similar to the Norton Commander of DOS fame. By executing mc at a shell prompt, a dual-pane view of the files is displayed. It contains drop-down menu choices and function keys to manipulate files. It also uses its own virtual file system, enabling it to mount FTP directories and display the contents of tar files, gzip tar files (.tar.gz or .tgz), bzip files, DEB files, and RPM files, as well as extract individual files from them. As if that is not enough, mc contains a File Undelete virtual file system for ext2/3 partitions. By using cd to “change directories” to an FTP server’s URL, you can transfer files using FTP. The default font chosen for Ubuntu makes the display of mc ugly when used in a tty console (as opposed to an xterm), but does not affect its performance.
In the interface, pressing the F9 key drops down the menu, and pressing F1 displays the Help file. A “feature” in the default GNOME terminal intercepts the F10 key used to exit mc, so use F9 instead to access the menu item to quit, or just click the menu bar at the bottom with your mouse. The configuration files are well documented, and it would appear easy to extend the functionality of mc for your system if you understand shell scripting and regular expressions. It is an excellent choice for file management on servers not running X.
Using rsync
An old favorite for backing up is rsync. One big reason for this is because rsync enables you to copy only those files that have changed since the last backup. So although the initial backup might take a long time, subsequent backups are much faster. It is also highly configurable and can be used with removable media such as USB hard drives or over a network. Here is one way to use rsync.
First, create an empty file and call it backup.sh:
matthew@seymour:~$ sudo touch backup.sh
Then, using your favorite text editor, enter the following command into the file and save it:rsync --force --ignore-errors --delete --delete-excluded --exclude-
from=/home/matthew-exclude.txt --backup --backup-dir='date +%Y-%m-%d' -av /
/media/externaldrive/backup/Seymour
Make the file executable:
matthew@seymour:~$ sudo chmod +x backup.sh
This command uses several options with rsync and puts them in a script that is quick and easy to remember and run. You can run the script at the command line using sudo sh ./backup.sh or as an automated cron job.
Here is a rundown of what is going on in the command. Basically, rsync is told to copy all new and changed files (what to back up) and delete from any existing backup any files that have been deleted on the source (and back them up in a special directory, just to be safe). It is told where to place the backup copy and is given details on how to deal with specific issues in the process. Read the rsync man page for more options and to customize to your needs.
Following are the options used here:
--force—Forces deletion of directories in the target location that are deleted in the source, even if the directories in the destination are not empty.
> --ignore-errors—Tells --delete to go ahead and delete files even when there are I/O errors.
> --delete—Deletes extraneous files from destination directories.
> --delete-excluded—Also deletes excluded files from destination directories.
> --exclude-from=/home/matt-exclude.txt—Prevents backing up files or directories listed in this file. (It is a simple list with each excluded directory on its own line.)
> --backup—Creates backups of files before deleting them from a currently existing backup.
> --backup-dir='date +%Y-%m-%d'—Creates a backup directory for the previously mentioned files that looks like this: 2013-07-08. Why this format for the date? Because it is standard, as outlined in ISO 8601 (see: http://www.iso.org/iso/home/standards/iso8601.htm). It is clear, works with scripts, and sorts beautifully, making your files easy to find.
> -av—Tells rsync to use archive mode and verbose mode.
> /—Denotes the directory to back up. In this case, it is the root directory of the source, so everything in the file system is being backed up. You could put /home here to back up all user directories or make a nice list of directories to exclude in the file system.
> /media/externaldrive/backup/seymour—Sets the destination for the backup as the /backup/seymour directory on an external hard drive mounted at /mount/externaldrive.
matthew@seymour:~$ rsync --force --ignore-errors --delete --delete-excluded
/media/externaldrive/backup/seymour /
This becomes even more useful when you think of ways to script its use. You could create an entry in crontab, as described in Chapter 14, “Automating Tasks and Shell Scripting.” Even better, you could set two computers to allow for remote SSH connections using private keys created with ssh-keygen, as described in Chapter 19, “Remote Access with SSH, Telnet, and VNC,” so that one could back up the files from one computer to the other computer without needing to login manually. Then you could place that in an automated script.
Networking
Laying the Foundation: The localhost Interface
The first thing that needs to be in place before you can successfully connect to a network or even to the Internet is a localhost interface, sometimes called a loopback interface, but more commonly referenced as lo. The TCP/IP protocol (see the section “Networking with TCP/IP” later in this chapter) uses this interface to assign an IP address to your computer and is needed for Ubuntu to establish a PPP interface.
You should not normally have to manually create a loopback interface because Ubuntu creates one automatically for you during installation. To check that one is set up, you can use the ifconfig command, which lists all networking interfaces available, including the lo interface if it exists, like this:
matthew@seymour:~$ ifconfig
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:270 errors:0 dropped:0 overruns:0 frame:0
TX packets:270 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:20748 (20.7 KB) TX bytes:20748 (20.7 KB)
Configuring the Loopback Interface Manually
The localhost interface’s IP address is specified in a text configuration file that is used by Ubuntu to keep record of various network-wide IP addresses. The file is called /etc/hosts and usually exists on a system, even if it is empty. The file is used by the Linux kernel and other networking tools to enable them to access local IP addresses and hostnames. If you have not configured any other networking interfaces, you might find that the file looks something like this:
127.0.0.1 localhost
127.0.1.1 seymour
# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts127.0.0.1 localhost
matthew@seymour:~$ sudo /sbin/ifconfig lo 127.0.0.1
matthew@seymour:~$ sudo /sbin/route add 127.0.0.1 lo
These commands create the localhost interface in memory (all interfaces, such as eth0 or ppp0, are created in memory when using Linux), and then add the IP address 127.0.0.1 to an internal (in-memory) table so that the Linux kernel’s networking code can keep track of routes to different addresses.
Use the ifconfig command as shown previously to test the interface.
The first line defines the special localhost interface and assigns it an IP address of 127.0.0.1. You might hear or read about terms such as localhost, loopback, and dummy interface; all these terms refer to the use of the IP address 127.0.0.1. The term loopback interface is used to describe how to Linux networking drivers, it looks as though the machine is talking to a network that consists of only one machine; the kernel sends network traffic to and from itself on the same computer. This is sometimes referred to as a dummy interface because the interface doesn’t really exist; it is not a real address as far as the outside world is concerned; it exists only for the local machine, to trick the kernel into thinking that it and any network-aware programs running that require a network interface to operate have one available without them actually being aware that the connection is a connection to the same machine. It is a dummy, not in the sense of stupid or silent, but in the sense that it is a mockup or substitute for something real.
Each networked Ubuntu machine on a LAN uses this same IP address for its localhost. If for some reason you discover that an Ubuntu computer does not have this interface, perhaps because some well-meaning person deleted it without understanding it was needed, you can use sudo and edit the /etc/hosts file to add the localhost entry as you saw previously and then use the ifconfig and route commands using your sudo permissions to create the interface like this:
Checking Connections with ping, traceroute, and mtr
If all worked properly in the preceding section, you should now be able to use the ping command to check that the interface is responding properly like this (using either localhost or its IP address):
matthew@seymour:~$ ping -c 3 localhost
PING localhost (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.154 ms
64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.159 ms
64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64 time=0.153 ms
--- localhost ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1998ms
rtt min/avg/max/mdev = 0.153/0.155/0.159/0.010 ms
Networking with TCP/IP
The basic building block for any network based on UNIX hosts is the Transport Control Protocol/Internet Protocol (TCP/IP) suite, which includes three protocols even though only two get to be in the abbreviation. The suite consists of the Internet Protocol (IP), Transport Control Protocol (TCP), and Universal Datagram Protocol (UDP). IP is the base protocol. The TCP/IP suite is packet based, which means that data is broken into little chunks on the transmit end for transmission to the receiving end. Breaking data up into manageable packets allows for faster and more accurate transfers. In TCP/IP, all data travels via IP packets, which is why addresses are referred to as IP addresses. It is the lowest level of the suite.
TCP is also a connection-based protocol. Before data is transmitted between two machines, a connection is established between them. When a connection is made, a stream of data is sent to the IP to be broken into the packets that are then transmitted. At the receiving end, the packets are put back in order and sent to the proper application port. TCP/IP forms the basis of the Internet; without it the Internet would be a very different place indeed, if it even existed. In contrast, UDP is a connectionless protocol. Applications using this protocol just choose their destination and start sending. UDP is normally used for small amounts of data or on fast and reliable networks. If you are interested in the internals of TCP/IP, see the “References” section at the end of this chapter for places to look for more information.
TCP/IP Addressing
To understand networking with Linux, you need to know the basics of TCP/IP addressing. Internet IP addresses (also known as public IP addresses) are different from those used internally on a local area network (LAN). Internet IP addresses are assigned (for the United States and some other hosts) by the American Registry for Internet Numbers, available at www.arin.net/. Entities that need an Internet address apply to this agency to be assigned an address. The agency assigns Internet service providers (ISPs) one or more blocks of IP addresses, which the ISPs can then assign to their subscribers.
You will quickly recognize the current form of TCP/IP addressing, known as IP version 4 (IPv4). In this method, a TCP/IP address is expressed of a series of four decimal numbers: a 32-bit value expressed in a format known as dotted-decimal format, such as 192.168.0.1. Each set of numbers is known as an octet (eight 1s and 0s, such as 10000000 to represent 128) and ranges from 0 to 255.
The first octet usually determines what class the network belongs to. There are three classes of networks:
Ports
Most servers on your network have perform more than one task. For example, web servers often have to serve both standard and secure pages. You might also be running an FTP server on the same host. For this reason, applications are provided ports to use to make “direct” connections for specific software services. These ports help TCP/IP distinguish services so that data can get to the correct application. If you check the file /etc/services, you see the common ports and their usage. For example, for FTP, HTTP, and POP3 (email retrieval server), you see the following:
ftp 21/tcp
http 80/tcp http # WorldWideWeb HTTP
pop3 110/tcp pop-3 # POP version 3
ports
IPV6 basics
IPv4 is based on 32-bit numbering and limits the number of available IP addresses to about 4.1 billion. This and how those addresses were assigned has led to the realization that there are not enough IPv4 addresses available for the number of devices that need IP addresses. This is only one of the problems with IPv4 that was noticed back in the 1990s. Others include large routing tables, which are lists of the routes to particular network destinations, and sometimes the network distances and topography associated with those routes. These tables are stored in routers and networked computers.
To deal with these issues, IPv6 uses 128-bit numbering that can theoretically allow well over 340,282,366,920,938,463,463,374,607,431,768,211,456 IP addresses, which is normally expressed in scientific notation as about 3.4*1038 addresses. That’s about 340 trillion, trillion, trillion addresses, meaning we are unlikely to run out again anytime soon. Gives each computer its own globally routable address. You don’t need NAT in IPv6 to translate IP addresses as packets pass through a routing device, as there are an adequate number of addresses available. We can go back to the easier-to-configure peer-to-peer style of Internet networking originally conceived of and used in the 1980s. Creates routing tables that are much smaller because fewer subroutes need to be generated.
IPv6 addresses are created using eight sets of numbers, like this:
F734:0000:0000:0000:3458:79B2:D07B:4620
Each of the eight sections is made of a four-digit number in hexadecimal, which means that each digit can from 0 to 9 or A to F (A=10, B=11, and so on). Hexadecimal is a denser format than binary. In binary, there are only two options, 0 or 1. This means that in hexadecimal, 4 digits can be used to represent 16 binary digits, like this:
Image Bin 0000000000000000 = Hex 0000 (or just 0)
Image Bin 1111111111111111 = Hex FFFF
Image Bin 1101010011011011 = Hex D4DB
So, a 128-bit address written in binary would be very long indeed. This 128-bit address written in binary and separated by dots 1111111111111111.1111111111111111.1111111111111111.1111111111111111.111111111111
1111.1111111111111111.1111111111111111.1111
is the same as this 128-bit address, written in hexadecimal and separated by colons:
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF
Subnetting
Within Class A and B networks, there can be separate networks called subnets. Subnets are considered part of the host portion of an address for network class definitions. For example, in the 128. Class B network, you can have one computer with an address of 128.10.10.10 and another with an address of 128.10.200.20; these computers are on the same network (128.10.), but they have different subnets (128.10.10. and 128.10.200.). Because of this, communication between the two computers requires either a router or a switch. Subnets can be helpful for separating workgroups within your company.
Often subnets can be used to separate workgroups that have no real need to interact with or to shield from other groups’ information passing among members of a specific workgroup. For example, if your company is large enough to have its own HR department and payroll section, you could put those departments’ hosts on their own subnet and use your router configuration to limit the hosts that can connect to this subnet. This configuration prevents networked workers who are not members of the designated departments from being able to view some of the confidential information the HR and payroll personnel work with.
Subnet use also enables your network to grow beyond 254 hosts and share IP addresses. With proper routing configuration, users might not even know they are on a different subnet from their co-workers. Another common use for subnetting is with networks that cover a wide geographic area. It is not practical for a company with offices in Chicago and London to have both offices on the same subnet, so using a separate subnet for each office is the best solution.
Subnet Masks
Subnet masks are used by TCP/IP to show which part of an IP address is the network portion and which part is the host. Subnet masks are usually referred to as netmasks. For a pure Class A network, the netmask is 255.0.0.0; for a Class B network, the netmask is 255.255.0.0; and for a Class C network, the netmask is 255.255.255.0. You can also use netmasks to deviate from the standard classes.
By using customized netmasks, you can subnet your network to fit your needs. For example, your network has a single Class C address. You have a need to subnet your network. Although this is not possible with a normal Class C subnet mask, you can change the mask to break your network into subnets. By changing the last octet to a number greater than zero, you can break the network into as many subnets as you need.
For more information on how to create customized subnet masks, see Day 6, “The Art of Subnet Masking,” in Sams Teach Yourself TCP/IP Network Administration in 21 Days. That chapter goes into great detail on how to create custom netmasks and explains how to create an addressing cheat sheet for hosts on each subnet. The Linux Network Administrator’s Guide also has good information about how to create subnets at www.tldp.org/LDP/nag2/index.html.
Broadcast, Unicast, and Multicast Addressing
Information can get to systems through three types of addresses: unicast, multicast, and broadcast. Each type of address is used according to the purpose of the information being sent, as explained here:
Image Unicast—Sends information to one specific host. Unicast addresses are used for Telnet, FTP, SSH, or any other information that needs to be shared in a one-to-one exchange of information. Although it is possible that any host on the subnet/network can see the information being passed, only one host is the intended recipient and will take action on the information being received.
Image Multicasting—Broadcasts information to groups of computers sharing an application, such as a video conferencing client or online gaming application. All the machines participating in the conference or game require the same information at precisely the same time to be effective.
Image Broadcasting—Transmits information to all the hosts on a network or subnet. Dynamic Host Configuration Protocol (DHCP) uses broadcast messages when the DHCP client looks for a DHCP server to get its network settings, and Reverse Address Resolution Protocol (RARP) uses broadcast messages for hardware address to IP address resolution. Broadcast messages use .255 in all the host octets of the network IP address. (10.2.255.255 broadcasts to every host in your Class B network.)
Telnet
Telnet is an older service. The client is part of the default installation, but is not activated by default. The server is not part of the default installation. This is because everything Telnet transmits and receives is in plain text, including passwords and other sensitive information. Telnet is generally not a good choice for communication. However, you might want to install Telnet for certain situations, such as connecting to a piece of equipment that doesn’t have SSH available, such as embedded systems where having a small OS footprint is important and more secure methods of communication are not available. In addition, sometimes Telnet is the quickest and easiest way to test newly installed services during configuration, such as a Postfix mail server. You might also want to install Telnet to learn about it and test it, simply because you might run across moments in the real world where no other option exists.
If you decide to install Telnet, use Synaptic or apt to install telnetd, which installs the server.
Remote Access
Telnet is an older service. The client is part of the default installation, but is not activated by default. The server is not part of the default installation. This is because everything Telnet transmits and receives is in plain text, including passwords and other sensitive information. Telnet is generally not a good choice for communication. However, you might want to install Telnet for certain situations, such as connecting to a piece of equipment that doesn’t have SSH available, such as embedded systems where having a small OS footprint is important and more secure methods of communication are not available. In addition, sometimes Telnet is the quickest and easiest way to test newly installed services during configuration, such as a Postfix mail server. You might also want to install Telnet to learn about it and test it, simply because you might run across moments in the real world where no other option exists.
If you decide to install Telnet, use Synaptic or apt to install telnetd, which installs the server.
SSH
If not installed already, you can install the OpenSSH server by adding the openssh-server package. As you might have guessed, sshd is the name for the SSH server daemon.
Start by configuring your firewall to allow connections through port 22. If this port is blocked, you cannot use SSH. See Chapter 20, “Securing Your Machines,” for help doing this.
Two different versions of SSH exist, SSH1 and SSH2. The latter is newer and more secure, comes with more features, and is the default in Ubuntu. Support for SSH1 clients is best left disabled so that older clients cannot connect. This is done by default in the /etc/ssh/sshd_config file on this line:
Protocol 2
If you have no other option and absolutely have to allow an older client to connect, add a new line:
Protocol 1
Although Telnet is worth keeping around as a fail-safe, last-resort option, SSH is superior in nearly every way. Telnet is fast but also unsecure. As stated earlier, it sends all your text, including your password, in plain text that can be read by anyone with the right tools. SSH, on the other hand, encrypts all your communication and so is more resource intensive but secure—even a government security agency sniffing your packets for some reason would still have a hard time cracking the encryption.
Andy Green, posting to the fedora-list mailing list, summed up the Telnet situation perfectly when he said, “As Telnet is universally acknowledged to encourage evil, the service telnetd is not enabled by default.” It is worthwhile taking the hint: Use Telnet as a last resort only.
To the surprise of many, OpenSSH actually is comprised of a suite of tools. We have already seen ssh, the Secure Shell command that connects to other machines, and sshd, the SSH server daemon that accepts incoming SSH connections. However, there is also sftp, a replacement for ftp, scp, and rcp.
You should already be familiar with the ftp command because it is the lowest common denominator system for handling FTP file transfers. Like Telnet, though, ftp is unsecure: It sends your data in plain text across the network, and anyone can sniff your packets to pick out a username and password. The SSH replacement, sftp, puts FTP traffic over an SSH link, thus securing it.
The rcp command might be new to you, largely because it is not used much anymore. Back in its day, rcp was the primary way of copying a single file to another server. As with ftp, scp replaces rcp by simply channeling the data over a secure SSH connection. The difference between sftp and scp is that the former enables you to queue and copy many files simultaneously, whereas the latter is usually used to just send one, although scp can be used with the -r option to send an entire directory at once. See the man page for details.
The most basic use of the scp command is to copy a file from your current machine to a remote machine. You can do that with the following command:
matthew@seymour:~$ scp test.txt 192.168.1.102:newtest.txt
matthew@seymour:~$ scp test.txt 192.168.1.102:subdir/stuff/newtest.txt
matthew@seymour:~$ scp test.txt usernamenewtest.txt
matthew@seymour:~$ scp 192.168.1.102:remote.txt.
sftp is a mix between ftp and scp. Connecting to the server uses the same syntax as scp—you can just specify an IP address to connect using your current username, or you can specify a username using username@ipaddress. You can optionally add a colon and a directory, as with scp. After you are connected, the commands are the same as ftp: cd, put, mput, get, quit, and so on.
In one of the scp examples, we copied a remote file locally. You can do the same thing with sftp with the following conversation:
√matthew@seymour:~$ sftp 192.168.1.102
There is a weak link in the SSH system, and, inevitably, it lies with users. No matter what lengths system administrators go to in training users to be careful with their passwords, monitors around the world have Post-it notes attached to them with pAssw0rd written on them. Sure, it has a mix of letters and numbers, but it can be cracked in less than a second by any brute-force method. Brute-forcing is the method of trying every password possibility, starting with likely words (such as password and variants, or god) and then just trying random letters (for example, a, aa, ab, ac, and so on).
Even very strong passwords are no more than about 16 characters; such passwords take a long time to brute-force but can still be cracked. The solution is to use key-based logins, which generate a unique, 1024-bit private and public key pair for your machine. These keys take even the fastest computers a lifetime to crack, and you can back them up with a password to stop others from using them.
Creating an SSH key is done through the ssh-keygen command, like this:
ssh-keygen –t dsa