Think for a moment. Other than logins to virtual terminals, how else do your users log into systems? Most likely (and, hopefully) through ssh.
You can control exactly who can ssh into a system by adding a line to the /etc/ssh/sshd_config file of the system running the SSH daemon.
There are two ways you can control this. One is through AllowGroups.
By default, all groups—meaning all users—can ssh into a system. The other way is through AllowUsers, where again, all users are allowed by default.
Suppose I want to allow only the users genisis, biko, and dru to ssh into a particular system. I could create a group called remote that contains those users:
# grep 100 /etc/group
#
# pw groupadd remote -g 100 -M genisis biko dru
In this example, I first double-checked that the group ID of 100 was not currently in use. I then created, with pw groupadd, the remote group with a GID of 100 (-g 100) and with those three members (-M genisis biko dru).
Now I can limit ssh access to just the members of that group:
# echo 'AllowGroups remote' >> /etc/ssh/sshd_config
Alternatively, I could have just added those three users directly:
# echo 'AllowUsers genisis biko dru' >>
/etc/ssh/sshd_config
Any user who does not match either AllowGroups or AllowUsers will still receive a password prompt when attempting to connect to the SSH daemon. However, the connection attempt will fail with a permission denied message, even if the user provides a correct username and password. The SSH daemon will print a message regarding the failed attempt to its console, sending a copy to /var/log/messages and emailing to root as part of the daily security run output.
To be even pickier, if your users always log in from the same system, you can do this:
AllowUsers genisis@10.0.0.2 biko@10.0.0.3 dru@10.0.0.4
However, don't be that picky if your users don't have static IPs!
Remember, if you make any changes to the SSH daemon's
configuration file, you'll need to send a "signal one" to sshd to notify it of the changes:
# killall -1 sshd
After informing sshd of the changes, immediately use a ssh client to test your changes. For example, if I instead add the line Allowusers genisis biko dru, I'll find that user nastygirl is still able to connect. Why? The parameters in /etc/ssh/sshd_config are case-sensitive. You don't want to find out six months later that anyone was allowed to connect when you thought you had restricted connections to certain users.
3.12.4 /etc/login.conf
We've restricted who can log in and from where for both local and remote ssh logins, but we still haven't restricted when those users can log in. To do that, let's look at some other options that are available in our old friend /etc/login.conf [Hack #30] .
This file supports the options times.allow and times.deny. For example, to allow all users to log in between 9:00 AM and 5:00 PM every Monday through Friday, add this line to the default:\ section:
:times.allow=Mo-Fr0900-1700:\
Once you introduce the times.allow option, access will automatically be denied for the time period not listed.
The converse also works. That is, you can specify the denied times in times.deny, and all other times will be allowed.
Remember, whenever you make a change to /etc/login.conf, rebuild the database with cap_mkdb /etc/login.conf and test your changes.
3.12.5 See Also
< Day Day Up >
< Day Day Up >
Chapter 4. Backing Up
• Introduction
• Section 35. Back Up FreeBSD with SMBFS
• Section 36. Create Portable POSIX Archives
• Section 37. Interactive Copy
• Section 38. Secure Backups Over a Network
• Section 39. Automate Remote Backups
• Section 40. Automate Data Dumps for PostgreSQL Databases
• Section 41. Perform Client-Server Cross-Platform Backups with Bacula
< Day Day Up >
< Day Day Up >
Introduction
I began gathering contributions for this book, it soon become obvious that there would be an entire chapter on backups. Not only do BSD users follow the mantra "backup, backup, backup," but every admin seems to have hacked his own solution to take advantage of the tools at hand and the environment that needs to be backed up.
If you're looking for tutorials on how to use dump and tar, you won't find them here. However, you will find nonobvious uses for their less well-known counterparts pax and cpio. I've also included a hack on backing up over ssh, to introduce the novice user to the art of combining tools over a secure network connection.
You'll also find scripts that fellow users have created to get the most out of their favorite backup utility. Finally, there are hacks that introduce some very useful open source third-party utilities.
< Day Day Up >
< Day Day Up >
Hack 35 Back Up FreeBSD with SMBFS
A good backup can save the day when things go wrong. A bad—or missing—backup can ruin the whole week.
Regular backups are vital to good administration. You can perform backups with hardware as basic as a SCSI tape drive using 8mm tape cartridges or as advanced as an AIT tape library system using
cartridges that can store up to 50 GB of compressed data. But what if you don't have the luxury of dedicated hardware for each server?
Since most networks are comprised of multiple systems, you can archive data from one server across the network to another. We'll back up a FreeBSD system using the tar and gzip archiving utilities and the smbutil and mount_smbfs commands to transport that data to network shares. These procedures were tested on FreeBSD 4.6-STABLE and 5.1-RELEASE.
4.2.1 Adding NETSMB Kernel Support
Since SMB is a network-aware filesystem, we need to build SMB support into the kernel. This means adding the proper options lines to the custom kernel configuration file. For information on building a custom kernel, see [Hack #54], the Building and Installing a Custom Kernel section (9.3) of the FreeBSD Handbook, and relevant information contained in /usr/src/sys/i386/conf.
Add the following options under the makeoptions section:
options NETSMB # SMB/CIFS requester options NETSMBCRYPTO # encrypted password support for SMB
options LIBMCHAIN # mbuf management library options LIBICONV
options SMBFS
Once you've saved your changes, use the make buildkernel and make installkernel commands to build and install the new kernel.
4.2.2 Establishing an SMB Connection with a Host System
The next step is to decide which system on the network to connect to.
Obviously, the destination server needs to have an active share on the network, as well as enough disk space available to hold your archives.
It will also need a valid user account with which you can log in. You'll probably also want to choose a system that's backed up regularly to removable media. I'll use a machine named smbserver1.
The smbutil and mount_smbfs commands both come standard with the base install of FreeBSD.
Their only requirements are the five kernel options listed in the preceding section.
Once you have chosen the proper host, make an SMB connection manually with the smbutil login command. This connection will remain active, allowing you to interact with the SMB server, until you issue the smbutil logout command. So, to log in:
# smbutil login //jwarner@smbserver1
Connection unmarked as permanent and will be closed when possible
4.2.3 Mounting a Share
Once you're sure you can manually initiate a connection with the host system, create a mount point where you can mount the remote share.
I'll create a mount point directory called /backup:
# mkdir /backup
Next, reestablish a connection with the host system and mount its share:
# smbutil login //jwarner@smbserver1 Password:
Connected to smbserver1
# mount_smbfs -N //jwarner@smbserver1/sharename /backup
Note that I used the -N switch to mount_smbfs to avoid having to supply a password a second time. If you prefer to be prompted for a password when mounting the share, simply omit the -N switch.
4.2.4 Archiving and Compressing Data with tar and gzip
After connecting to the host server and mounting its network share, the next step is to back up and copy the necessary files. You can get as complicated as you like, but I'll create a simple shell script, bkup, inside the mounted share that compresses important files and directories.
This script will make compressed archives of the /boot, /etc, /home, and /usr/local/etc directories. Add to or edit this list as you see fit. At a minimum, I recommend including the /etc and /usr/local/etc directories, as they contain important configuration files. See man hier for a
complete description of the FreeBSD directory structure.
#!/bin/sh
# script that backs up the following four directories:
tar cvvpzf boot.tar.gz /boot tar cvvpzf etc.tar.gz /etc tar cvvpzf home.tar.gz /home
tar cvvpzf usr_local_etc.tar.gz /usr/local/etc
This script is an example to get you started. There are many ways to use tar. Read man 1 tar
carefully, and tailor the script to suit your needs.
Be sure to make this file executable:
# chmod 755 bkup
Run the script to create the archives:
# ./bkup
tar: Removing leading / from absolute path names in the archive.
drwxr-xr-x root/wheel 0 Jun 23 18:19 2002 boot/
drwxr-xr-x root/wheel 0 May 11 19:46 2002 boot/defaults/
-r--r--r-- root/wheel 10957 May 11 19:46 2002 boot/defaults/loader.conf
-r--r--r-- root/wheel 512 Jun 23 18:19 2002 boot/mbr
(snip)
After the script finishes running, you'll have *.tar.gz files of the directories you chose to archive:
# ls | more
Once you've tested your shell script manually and are happy with your results, add it to the cron scheduler to run on scheduled days and times.
Remember, how you choose to implement your backups isn't
important—backing up regularly is. Facing the problem of deleted or corrupted data isn't a matter of "if" but rather a matter of "when." This is why good backups are essential.
4.2.5 Hacking the Hack
Things to consider when modifying the script to suit your own purposes:
•
• Add entries to automatically mount and unmount the share (see [Hack #68] for an example).
•
• Use your backup utility of choice. You're not limited to just tar!
4.2.6 See Also
• The Building and Installing a Custom Kernel section of the FreeBSD Handbook (
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbo ok/kernelconfig-building.html)
< Day Day Up >
< Day Day Up >
Hack 36 Create Portable POSIX Archives
Create portable tar archives with pax.
Some POSIX operating systems ship with GNU tar as the default tar utility (NetBSD and QNX6, for example). This is problematic because the GNU tar format is not compatible with other vendors' tar
implementations. GNU is an acronym for "GNU's not UNIX"—in this case, GNU's not POSIX either.
4.3.1 GNU Versus POSIX tar
For filenames or paths longer than 100 characters, GNU uses its own
@LongName tar format extension. Some vendors' tar utilities will choke on the GNU extensions. Here is what Solaris's archivers say about such an archive:
% pax -r < gnu-archive.tar
pax: ././@LongLink : Unknown filetype
% tar xf gnu-archive.tar tar: directory checksum error
There definitely appears to be a disadvantage with the distribution of non-POSIX archives. A solution is to use pax to create your tar archives in the POSIX format. I'll also provide some tips about using pax's features to compensate for the loss of some parts of GNU tar's extended feature set.
4.3.2 Replacing tar with pax
The NetBSD and QNX6 pax utility supports a tar interface and can also read the @LongName GNU tar format extension. You can use pax as your tar replacement, since it can read your existing
GNU-format archives and can create POSIX archives for future backups. Here's how to make the quick conversion.
First, replace /usr/bin/tar. That is, rename GNU tar and save it in another directory, in case you ever need to restore GNU tar to its previous location:
# mv /usr/bin/tar /usr/local/bin/gtar
Next, create a symlink from pax to tar. This will allow the pax utility to emulate the tar interface if invoked with the tar name:
# ln -s /bin/pax /usr/bin/tar
Now when you use the tar utility, your archives will really be created by pax.
4.3.3 Compress Archives Without Using Intermediate Files
Let's say you're on a system that doesn't have issues with tar. Why else would you consider using pax as your backup solution?
For one, you can use pax and pipelines to create compressed archives, without using intermediate files. Here's an example pipeline:
% find /home/kirk -name '*.[ch]' | pax -w | pgp -c
The pipeline's first stage uses find to generate the exact list of files to archive. When using tar, you will often create the file list using a subshell. Unfortunately, the subshell approach can be unreliable. For example, this user has so much source code that the complete file list does not fit on the command line:
% tar cf kirksrc.tar $(find /home/kirk -name '*.[ch]')
/bin/ksh: tar: Argument list too long
However, in more cases, the pipeline approach will work as expected.
During the second stage, pax reads the list of files from stdin and writes the archive to stdout. The pax found on all of the BSDs has built-in gzip support, so you can also compress the archive during this stage by adding the -z argument.
When creating archives, invoke pax without the -v (verbose) argument.
This way, if there are any pax error messages, they won't get lost in the extra output.
The third stage compresses and/or encrypts the archive. An
intermediate tar archive isn't required as the utility reads its data from the pipeline. This example uses pgp, the Pretty Good Privacy encryption system, which can be found in the ports collection.
4.3.4 Attribute-Preserving Copies
POSIX provides two utilities for copying file hierarchies: cp -R and pax -rw. For regular users, cp -R is the common method. But for
administrative use, pax -rw preserves more of the original file attributes, including hard-link counts and file access times. pax -rw also gives you a better copy of the original file hierarchy.
For an example, let's back up three executables. Note that egrep, fgrep, and grep are all hard links to the same executable.The link count is three, and all have the same inode number. ls -li displays the inode number in column 1 and the link count in column 3:
# ls -il /usr/bin/egrep /usr/bin/fgrep /usr/bin/grep 31888 -r-xr-xr-x 3 root wheel 73784 Sep 8 2002
With pax -rw, we will create one executable with the same date as the original:
# pax -rw /usr/bin/egrep /usr/bin/fgrep /usr/bin/grep /tmp/
# ls -il /tmp/usr/bin/
47 -r-xr-xr-x 3 root wheel 73784 Sep 8 2002 egrep 47 -r-xr-xr-x 3 root wheel 73784 Sep 8 2002 fgrep 47 -r-xr-xr-x 3 root wheel 73784 Sep 8 2002 grep
Can we do the same thing using cp -R? Nope. Instead, we create three new files, each with a unique inode number, a link count of one, and a new date:
# rm /tmp/usr/bin/*
# cp -R /usr/bin/egrep /usr/bin/fgrep /usr/bin/grep /tmp/usr/bin/
# ls -il /tmp/usr/bin/
49 -r-xr-xr-x 1 root wheel 73784 Dec 19 11:26 egrep 48 -r-xr-xr-x 1 root wheel 73784 Dec 19 11:26 fgrep 47 -r-xr-xr-x 1 root wheel 73784 Dec 19 11:26 grep
4.3.5 Rooted Archives and the Substitution Argument
If you have ever used GNU tar and received this message:
tar: Removing leading `/' from absolute path names in the archive
then you were using a tar archive that was rooted, where the files all had absolute paths starting with the forward slash (/). It is not a good idea to clobber existing files unintentionally with foreign binaries, which is why the GNU tar utility automatically strips the leading / for you.
To be safe, you want your unarchiver to create files relative to your current working directory. Rooted archives try to violate this rule by creating files relative to the root of the filesystem, ignoring the current working directory. If that archive contained /etc/passwd, unarchiving it could replace your current password file with a foreign copy. You may be surprised when you cannot log into your system anymore!
You can use the pax substitution argument to remove the leading /. This will ensure that the unarchived files will be created relative to your current working directory, instead of at the root of your filesystem:
# pax -A -r -s '-^/--' < rootedarchive.tar
Here, the -A argument requests that pax not strip the leading / automatically, as we want to do this ourselves. This argument is required only to avoid a bug in the NetBSD pax implementation that interferes with the -s argument. We also want pax to unarchive the file, so we pass the -r argument.
The -s argument specifies an ed-style substitution expression to be performed on the destination pathname. In this example, the leading / will be stripped from the destination paths. See man ed for more information.
If we used the traditional / delimiter, the substitution expression would be /^\///. (The second / isn't a delimiter, so it has to be escaped with a
\.) You will find that / is the worst delimiter, because you have to escape all the slashes found in the paths. Fortunately, you can choose another delimiter. Pick one that isn't present in the paths, to minimize the number of escape characters you have to add. In the example, we used the - character as the delimiter, and therefore no escapes were required.
The substitution argument can be used to rename files for a beta software release, for example. Say you develop X11R6 software and have multiple development versions on your box:
/usr/X11R6.saturday /usr/X11R6.working /usr/X11R6.notworking /usr/X11R6.released
and you want to install the /usr/X11R6.working directory as usr/X11R6 on the beta system:
# pax -A -w -s '-^/usr/X11R6.working-usr/X11R6-' /usr/X11R6.working \
> /tmp/beta.tar
This time, the -s argument specifies a substitution expression that will replace the beginning of the path /usr/X11R6.working with usr/X11R6 in the archive.
4.3.6 Useful Resources for Multiple Volume Archives
POSIX does not specify the format of multivolume archive headers, meaning that every archiver may use a different intervolume header format. If you have a lot of multivolume tar archives and plan to switch to a different tar implementation, you should test whether you can still recover your old multivolume archives.
This practice may have been more common when Minix/QNX4 users archived their 20 MB hard disks to a stack of floppy disks.
Minix/QNX4 users had the vol utility to handle multiple volumes;
instead of adding the multivolume functionality to the archiver itself, it was handled by a separate utility. You should be able to switch
archiver implementations transparently because vol did the splitting, not the archiver.
The vol utility performs the following operations:
•
• At the end-of-media, prompts for the next volume
•
• Verifies the ordering of the volumes
•
• Concatenates the multiple volumes
Unfortunately, the vol utility isn't part of the NetBSD package
collection. If you create a lot of multivolume archives, you may want to look into porting one of the following utilities:
vol
Creates volume headers for tar; developed by Brian Yost and available at
http://groups.google.com/groups?selm=80%40mirror.UUCP&output=g plain
multivol
Provides multiple volume support; created by Marc Schaefer and
Provides multiple volume support; created by Marc Schaefer and