Basic network access: servers

Разбить на страницы

Показывать лекцию целиком

In the previous chapter, we saw how to use clients to access other systems. This is only half the picture, of course. At the other end of the link, we need servers to provide this service. For each client, there is a server (a daemon) whose name is usually derived from the client name by adding a d to it:

Server daemons for basic services
Client	Server
ssh	sshd
telnet	telnetd
sftp	sftp-server
ftp	ftpd
rsync	rsyncd
(browser)	httpd
(NFS)	nfsd

In addition to these servers, we look at a few others in other chapters:

We've already looked at Xservers briefly in Chapter 8, Taking control, and we'll see more in Chapter 28, XFree86 in depth.

Chapter 21 discussed DNS name servers.

Chapter 27 discusses Mail Transport Agents or MTAs, also referred to as mail servers.

Some servers don’t need any configuration, and about all you need to do is to start them. Others, like web servers, can be very complicated. None of the complication is related to FreeBSD. For example, the issues involved in configuring apache are the same whether you run it with FreeBSD, NetBSD, Linux or Solaris. There are several good books, each at least the size of this one, on the detailed setup of some of these servers. In this chapter we'll look at how to get the servers up and running in a basic configuration, and where to turn for more information.

Running servers from inetd

If you look at /etc/services, you'll find that there are over 800 services available, most of which are only supported on a small number of machines. It's not always the best idea to start up a daemon for every possible service you may want to offer. IP supplies an alternative: inetd, the Internet daemon, sometimes called a super-server, which listens on multiple ports. When a request arrives on a specific port, inetd starts a daemon specific to the port. For example, FreeBSD supports anonymous ftp, but most people don't receive enough requests to warrant having the ftp daemon, ftpd, running all the time. Instead, inetd starts an ftpd when a request comes in on port 21.

At startup, inetd reads a configuration file /etc/inetd.conf to determine which ports to monitor and what to do when a message comes in. Here's an excerpt:

#$FreeBSD: src/etc/inetd.conf,v 1.58 2002/08/09 17:34:13 gordon Exp $ #
#Internet server configuration database
#
#ftp     stream  tcp   nowait  root  /usr/libexec/lukemftpd  ftpd -l -r
#ftp     stream  tcp   nowait  root  /usr/libexec/ftpd       ftpd -l
#ftp     stream  tcp6  nowait  root  /usr/libexec/ftpd       ftpd -l
#telnet  stream  tcp   nowait  root  /usr/libexec/telnetd    telnetd
#telnet  stream  tcp6  nowait  root  /usr/libexec/telnetd    telnetd
#shell   stream  tcp   nowait  root  /usr/libexec/rshd       rshd
#shell   stream  tcp6  nowait  root  /usr/libexec/rshd       rshd
#login   stream  tcp   nowait  root  /usr/libexec/rlogind    rlogind
#login   stream  tcp6  nowait  root  /usr/libexec/rlogind    rlogind
#exec    stream  tcp   nowait  root  /usr/libexec/rexecd     rexecd
#shell   stream  tcp6  nowait  root  /usr/libexec/rshd       rshd

This file has the following format:

• The first column is the service on which inetd should listen. If it starts with a # sign, it's a comment, and inetd ignores it. You'll note in this example that all the listed services have been commented out. Unless you run the daemon independently of inetd, a request for one of these services will be rejected with the message:

Unable to connect to remote host: Connection refused

The next three columns determine the nature of the connection, the protocol to use, and whether inetd should wait for the process to complete before listening for new connections. In the example, all the services are TCP, but there are entries both for tcp (the normal TCP protocol for IP Version 4) and tcp6 (the same service for IP Version 6).

The next column specifies the user as which the function should be performed.

The next column is the full pathname of the program (almost always a daemon) to start when a message comes in. Alternatively, it might be the keyword internal, which specifies that inetd should perform the function itself.

All remaining columns are the parameters to be passed to the daemon.

Older versions of UNIX ran inetd as part of the startup procedure. That isn't always necessary, of course, and for security reasons the default installation of FreeBSD no longer starts it. You can change that by adding the following line to your /etc/rc.conf:

inetd_enable="YES"  # Run the network daemon dispatcher (YES/NO).

To enable services in /etc/inetd.conf, it may be enough to remove the comment from the corresponding line. This applies for most the services in the example above. In some cases, though, you may have to perform additional steps. For example, lukemftpd, an alternative ftpd, and nntpd, the Network News Transfer Protocol, are not part of FreeBSD: they're in the Ports Collection. Also, nntpd is intended to run as user use net, which is not in the base system.

The other daemons are not mentioned in /etc/inetd.conf:

The preferred way to run sshd is at system startup. As we'll see, the startup is quite slow, so it's not a good idea to run it from /etc/inetd.conf though it is possible—see the man page if you really want to.

sftp-server is the server for sftp. It gets started from sshd.

httpd, the Apache Web Server, also has quite a long startup phase that makes it impractical to start it from /etc/inetd.conf. Note also that httpd requires a configuration file. We'll look at that on page 455.

By contrast, it's perfectly possible to start rsyncd from inetd. It's not included in the standard /etc/inetd.conf file because it's a port. Yes, so are lukemftpd and nntpd. It's just a little inconsistent. This is the line you need to put in /etc/inetd.conf to start rsyncd.

rsync stream tcp nowait root /usr/local/bin/rsync rsync –daemon

The name rsync is not a typo. rsync and rsyncd are the same thing; it's the --daemon option that makes rsync run as a daemon.

inetd doesn't notice alterations to /etc/inetd.conf automatically. After modifying the file, you must send it a SIGHUP signal:

# killall -HUP inetd

You can write -1 instead of -HUP. This causes inetd to re-read /etc/inetd.conf.

Instead of starting daemons via inetd, you can start them at boot time. inetd is convenient for servers that don't get run very often, but if you make frequent connections, you can save overhead by running the servers continuously. On the other hand, it's not practical to start rshd, rlogind, rexecd or telnetd at boot time: they're designed to be started once for each session, and they exit after the first connection closes. We'll look at starting the other daemons in the following sections, along with their configuration.

Configuring ftpd

Normally you'll run ftpd from inetd, as we saw above. If you want to run it directly, perform the following steps:

Add the following line in /etc/rc.local:

echo -n 'starting local daemons:' #put your local stuff here echo " ftpd"  ftpd -D

The option -D tells ftpd to run as a daemon. You will possibly want other options as well; see the discussion below.

Comment out the ftp line in /etc/inetd.conf by adding a hash mark (#) in front of it:

#  ftp  stream   tcp  nowait  root  /usr/libexec/ftpd  ftpd -l

Either reboot, or cause inetd to re-read its configuration file:

#  killall -1 inetd  send a SIGHUP

If you don't perform this step, inetd keeps the ftp port open, and ftpd can't run.

For security reasons, you will probably want to add options such as logging and anonymous ftp. We'll look at how to do that in the next two sections.

anonymous ftp

Anonymous ftp gives you a couple of security options:

It restricts access to the home directory of user ftp. From the point of view of the remote user, ftp's home directory is the root directory, and he cannot access any files outside this directory. Note that this means that you can't use symbolic links outside the ftp directory, either.

It restricts access to the machine generally: the user doesn't learn any passwords, so he has no other access to the machine.

In addition, you can start ftpd in such a manner that it will allow only anonymous ftp connections.

There are a number of preparations for anonymous ftp:

Decide on a directory for storing anonymous ftp files. The location will depend on the amount of data you propose to store there. By default, it's /var/spool/ftp.

Create a user ftp, with the anonymous ftp directory as the home directory and the shell /dev/null. Using /dev/null as the shell makes it impossible to log in as user ftp, but does not interfere with the use of anonymous ftp. ftp can be a member of group bin or you can create a new group ftp by adding the group to /etc/group. See page 145 for more details of adding users, and the man page group(5) for adding groups.

Create subdirectories ~ftp/bin and ~/ftp/pub. It is also possible to create a directory for incoming data. By convention its name is ~ftp/incoming. This is a very bad idea if you're connected to the global Internet: it won't belong before people start using your system as a server for illicit data. Only use this option if you have some other method of stopping unauthorized access.

Set the ownership of the directories like this:

dr-xr-xr-x     2 ftp     ftp  512 Feb 28 12:57 bin
drwxrwxrwx     2 ftp     ftp  512 Oct   7 05:55 incoming
drwxrwxr-x   20 ftp     ftp  512 Jun   3 14:03 pub

This enables read access to the pub directory and read-write access to the incoming subdirectory.

If you have a lot of files that are accessed relatively in frequently, it's possible you will find people on the Net who copy all the files that they see in the directory. Sometimes you'll find multiple connections from one system copying all the files in parallel, which can cause bandwidth problems. In some cases, you might find it more appropriate to distribute the names individually, and to limit access to reading the directories. You can do this by setting the permissions of pub and its subdirectories like this:

d--x--x-- x  20 ftp    ftp  512 Jun  314:03 pub

This allows access to the files, but not to the directory, so the remote user can't find the names of the files in the directory.

Copy the following files to ~ftp/bin: /usr/bin/compress, /usr/bin/gzip, /usr/bin/gunzip, /bin/ls, /usr/bin/tar and /usr/bin/uncompress. The view of anonymous ftp users is restricted to the home directory, so all programs that are to be executed must also be in this directory.

You can ("hard") link the files if you want (and if the directory is on the same file system), but symbolic links will fail, since they contain path names that do not point to the correct place when running in the anonymous ftp environment.

Restricting access and logging

A number of ftpd options make it easier to control and monitor ftp access:

The -l option logs each session, whether successful or not, to syslogd with the facility LOG_FTP. To enable this logging, your /etc/syslog.conf should contain a line like

ftp.*      /var/log/ftpd

In addition, the file /var/log/ftpd must exist. If it doesn't, create it with:

# touch /var/log/ftpd

The -l option has two levels: if you specify it once, it logs connections only. If you specify it twice, it also lists the files that are transferred.

The -S option logs all anonymous transfers to the file /var/log/ftpd.

You can restrict access to only anonymous ftp with the -A option.

There are a number of other options; see the man page ftpd(8) for further details.

In addition to these options, when a real user establishes a connection, ftpd checks the user's shell. If it is not listed in /etc/shells, ftpd will deny the connection. This can be useful if you don't want specific users to access the system: give them a different shell, such as /usr/bin/sh instead of /bin/sh, and ensure that /usr/bin/sh is not in /etc/shells.

Log file format

The format of the log files is a little unusual. You'll see things like:

Oct 12 16:32:04 freebie ftpd[8691]: ANONYMOUS FTP LOGIN FROM adam.adonai.net, leec@a donainet
Oct 12 18:33:32 freebie ftpd[9007]: connection from gateway.smith.net.au
Oct 12 18:33:37 freebie ftpd[9007]: ANONYMOUS FTP LOGIN FROM gateway.smith.net.au, m
ike
Oct 12 21:36:28 freebie ftpd[9369]: connection from grisu.bik-gmbh.de
Oct 12 21:36:29 freebie ftpd[9369]: ANONYMOUS FTP LOGIN FROM grisu.bik-gmbh.de, harv
est@
Oct 12 21:36:37 1997!harvest@!grisu.bik-gmbh.de!/pub/cfbsd/README!9228!1 
Oct 12 21:37:05 freebie ftpd[9371]: connection from grisu.bik-gmbh.de
Oct 12 21:37:06 freebie ftpd[9371]: ANONYMOUS FTP LOGIN FROM grisu.bik-gmbh.de, harv
est@
Oct 13 09:38:19 freebie ftpd[13514]: connection from 151.197.101.46
Oct 13 09:38:21 freebie ftpd[13514]: ANONYMOUS FTP LOGIN FROM 151.197.101.46, bmc@ho
vercraft.willscreek.com
Oct 13 09:38:58 1997!bmc@hovercraft.willscreek.com!151.197.101.46!/pub/cfbsd/dear-re viewer!8890!1
Oct 13 09:41:42 1997!bmc@hovercraft.willscreek.com!151.197.101.46!/pub/cfbsd/txt/26-netdebug.txt.gz!12188!1
Oct 13 09:42:05 1997!bmc@hovercraft.willscreek.com!151.197.101.46!/pub/cfbsd/txt/C-p ackages.txt.gz!37951!1
Oct 13 09:59:07 freebie ftpd[14117]: connection from 151.197.101.46
Oct 13 09:59:08 freebie ftpd[14117]: ANONYMOUS FTP LOGIN FROM 151.197.101.46, bmc@ho vercraft.willscreek.com
Oct 13 09:59:24 1997!bmc@hovercraft.willscreek.com!151.197.101.46!/pub/cfbsd/txt/D-b iblio.txt.gz!1815!1

This log excerpt shows three kinds of message:

The messages starting with the text connection from occur when an ftp connection is made. They don't mean that any permission to access has been given. These messages are logged by the -l option.

The ANONYMOUS FTP LOGIN messages show that somebody has logged in anonymously. The name follows, not always in the required username format. The standard ftpd does not enforce this requirement; you may find something that does in the Ports Collection. These messages are logged by the -S option.

The lines full of ! marks show files being transferred. The ! marks delimit the fields, which are:

The year, as an extension of the timestamp.

The user ID.

The IP address of the system to which the data is transferred.

The name of the file transferred.

The number of bytes transferred.

Running sshd

Normally you start sshd from the system configuration file /etc/rc.conf:

sshd_enable="YES"  # Enable sshd

That's all you need to do for sshd. You can also start it simply with:

#sshd

sshd reads a configuration file /etc/ssh/sshd_config. Like its companion /etc/ssh/ssh_config, it contains mainly commented-out lines showing the default values. Most of them don't require change, but the following entries may be of interest:

Protocol states which ssh protocols to use, and in which order. By default, sshd tries protocol 2 first, and falls back to protocol 1 if protocol 2 fails. You might consider setting it to use only protocol 2.

When PermitRootLogin is set to yes, you can log in as root via ssh. Normally it's disabled.

Set PasswordAuthentication to no if you want all access to be via key exchange (see page 420 for more details).

If you want to run sftp-server, add the following line to /etc/ssh/sshd_config:

Subsystem  sftp /usr/libexec/sftp-server

It should be present by default.

rsyncd

As we've seen, rsyncd is just another name for rsync. You don't need to do any specific configuration to start it: it gets started from sshd, so all you need to do is to ensure that sshd gets started.

Starting rsyncd isn't enough, though: it needs configuration. Create a file /usr/local/etc/rsyncd.conf with contents something like this:

motd file = /usr/local/etc/rsyncd.txt
log file = /var/log/rsyncd.log
transfer logging = true
[groggy]
    path = /home/grog/public_html
    uid = grog
    read only = yes
    list = yes
    comment = Greg's web pages
    hosts allow = 223.147.37.0/24
[tivo]
    path = /var/tivo
    uid = grog
    read only = no
    list = yes
    comment = TiVo staging area
    hosts allow = tivo.example.org

This is the configuration file used in the server examples in Chapter 24. It consists of two parts: a global part at the beginning, with settings that apply to all modules, and one or more module parts describing files that the server will supply.

The global options here specify the motd file, a file whose contents are printed when you list modules (the ''be gentle'' message in the examples), and that transfers should be logged to /var/log/rsyncd.log. The log output looks something like this:

2002/10/24 13:31:49 [16398] send presto.example.org [192.109.197.74] groggy () slash
dot/topicscience.gif 1083
2002/10/24 13:31:49 [16398] send presto.example.org [192.109.197.74] groggy () slash
dot/topicsecurity.gif 3034
2002/10/24 13:31:49 [16398] send presto.example.org [192.109.197.74] groggy () slash
dot/topictv.jpg 951
2002/10/24 13:31:49 [16398] send presto.example.org [192.109.197.74] groggy () slide
.pdf 40470
2002/10/24 13:31:49 [16398] send presto.example.org [192.109.197.74] groggy () stock
whip.html 1602

The next part of the configuration file describes modules, directory hierarchies that rsyncd makes available. If you're used to Microsoft-style configuration files, this will seem relatively familiar. The module names are enclosed in square brackets ([]), and they don't have to have any relationship with the name of the directory. In this case we have two modules. Both have a comment, a descriptive text printed out when you list the modules, and both allow listing the name of the module (list = yes). In addition:

Module groggy makes available the directory /home/grog/public_html, my web pages, for read-only access. rsyncd accesses the module as user grog. Any host on the 256 address block starting with 223.147.37.0 can access the data.

Module . Again rsyncd accesses the data as user grog.

There are a large number of other options for rsyncd, but this example shows the most important ones. See the man page rsyncd.conf(5) for more information.

Setting up a web server

FreeBSD is a system of choice for running web servers, so it's not surprising that a large number are available. Probably the most popular is apache, which is available in the Ports Collection. Install with:

# cd /usr/ports/www/apache13
# make install

In future versions, the name apache13 will change. Apache comes with a lot of documentation in HTML format (of course), which is installed in /usr/local/share/doc/apache/manual. You might find it useful to put a symbolic link to it in your web home directory:

# cd /usr/local/www/data
# ln -s /usr/local/share/doc/apache/manual apachedoc

After this, you can access the documentation at (for example) http://www.example.org/apachedoc/.

Configuring apache

The Apache port uses the following directories:

The configuration files are in the directory hierarchy /usr/local/etc/apache. The port installs prototype configuration files, but they need to be modified.

By default, the web pages are in will have the URL http://www.example.org/foo.html.You may find it a good idea to change the directory to the /var file system in a location such as /var/www/data. We'll look at how to do that with the DocumentRoot entry in the configuration file.

Icons for Apache's own use are stored in /usr/local/www/icons. You can't access these icons by URI, so don't put your own images here.

CGI scripts are stored in /usr/local/www/cgi-bin.

The configuration file

The apache configuration file is /usr/local/etc/apache/httpd.conf. Older versions of apache also used the files /usr/local/etc/apache/access.conf and /usr/local/etc/apache/srm.conf. The division between these three files was relatively arbitrary, and the current recommendation is to not use these files, but to put their content in /usr/local/etc/apache/httpd.conf instead. See the apache documentation if you need to change the other files.

httpd.conf

Probably the best way to understand httpd.conf is to read through it. It's pretty long and contains a large number of comments. Most entries can be left the way there are, so we won't list the entire file here: instead we'll look at the parameters that may need change. We'll look at the system-wide features in the following list, and host-related features in the next section.

ServerType states whether you start it from inetd or standalone (the default). It's not a good idea to start httpd from inetd, so you should leave this entry unchanged.

ServerRoot claims to be the path to the configuration files, but in fact the files are stored in the subdirectory etc/apache of this directory. You shouldn't need to change it.

The comments about ScoreBoardFile suggest that you should check to see if the system creates one. Don't bother: FreeBSD doesn't create this file, and you don't need to worry about it.

The Keep-Alive extension to HTTP, as defined by the HTTP/1.1 draft, allows persistent connections. These long-lived HTTP sessions allow multiple requests to be sent over the same TCP connection, and in some cases have been shown to result in an almost 50% speedup in latency times for HTML documents with lots of images.

The parameters MinSpareServers, MaxSpareServers, StartServers, Max-Clients and MaxRequestsPerChild are used for server tuning. The default values should work initially, but if you have a lot of Web traffic, you should consider changing them.

The next area of interest is a large list of modules. A lot of apache functionality is optional, and you include it by including a module. We'll look at this in more detail below.

The parameter ProxyRequests allows Apache to function as a proxy server. We'll look at this in more detail below.

The parameters starting with Cache apply only to proxy servers, so we'll look at them below as well.

The Listen parameter defines alternate ports on which Apache listens.

Directorylndex is a list of names that httpd recognizes as the main page ("index") in the directory. Traditionally it's index.html. This is the means by which httpd changes a directory name into an index. It searches for the names in the order specified. For example, if you're using PHP, Directorylndex gets set to the string index.php index.php3 index.html, and that's the sequence in which it looks for a page.

The file ends with a commented out VirtualHost section. We'll look at it in detail in the next section, along with a number of parameters that appear elsewhere in the configuration file, but that relate to virtual hosts.

Virtual hosts

Running and maintaining a web server is enough work that you might want to use the same server to host several sets of web pages, for example for a number of different organizations. apache calls this feature virtual hosts, and it offers a lot of support for them. Theoretically, all your hosts can be virtual, but the configuration file still contains additional information for a "main" server, also called a "default" server. The default configuration does not have any virtual servers at all, though it does contain configuration information.

There's a good reason to keep the "main" server information: it serves as defaults for all virtual hosts, which can make the job of adding a virtual host a lot easier.

Consider your setup at http://example.org: you may run your own web pages and also a set of pages for http://biguser.com (see page 310). To do this, you add the following section to /usr/local/etc/apache/httpd.conf:

<VirtualHost *>
ServerAdmin grog@example.org
DocumentRoot /usr/local/www/biguser      Where we put the web pages
ServerName www.biguser.com               the name that the server will claim to be
ServerAlias biguser.com                  alternative server name
ErrorLog /var/log/biguser/error_log
TransferLog /var/log/biguser/access_log
Options +FollowSymLinks
Options +SymLinksIfOwnerMatch
</VirtualHost>

If you look at the default configuration file, you'll find most of these parameters, but not in the context of a VirtualHost definition. They are the corresponding parameters for the "main" web server. They have the same meaning, so we'll look at them here.

ServerAdmin is the mail ID of the system administrator. For the main server, it's set to you@your.address, which obviously needs to be changed. You don't necessarily need a ServerAdmin for each virtual domain; that depends on how you run the system.

Next you can put information about individual data directories. The default server first supplies defaults for all directories:

<Directory />
  Options FollowSymLinks
  AllowOverride None
</Directory>

The / in the first line indicates the local directory to which these settings should apply. For once, this is really the root directory and not DocumentRoot: they're system-wide defaults, and though you don't have to worry about apache playing around in your root file system, that's the only directory of which all other directories are guaranteed to be a subdirectory. The Options directive ensures that the server can follow symbolic links belonging to the owner. Without this option, symbolic links would not work. We'll look at the AllowOverride directive in the discussion of the .htaccess file below.

There's a separate entry for the data hierarchy:

<Directory "/usr/local/www/data">
  Options Indexes FollowSymLinks MultiViews
  AllowOverride None
  Order allow,deny
  Allow from all
</Directory>

In this case, we have two additional options:

Indexes allows httpd to display the contents of a directory if no index file, with a name defined in DirectoryIndex, is present. Without this option, if there is no index file present, you will not be able to access the directory at all.

MultiViews allows content-based multiviews, which we don't discuss here.

Note that if you change the name of the default data directory, you should also change the name on the Directory invocation.

We'll look at the remaining entries in more detail when we see them again in the discussion of the .htaccess file.

Normally you should set ServerName. For example, www.example.org is a CNAME for freebie.example.org (see page 370), and if you don't set this value, clients will access www.example.org, but the server will return the name freebie.example.org.

httpd can maintain two log files, an access log and an error log. We'll look at them in the next section. It's a good idea to keep separate log files for each domain.

You should have a default ) and get the (default) web page for http://www.example.org. The default page should not match any other host. Instead, it should indicate that the specified domain name is invalid.

For the same reason, it's a good idea to have a and http://biguser.com.

The directive Options +SymLinksIfOwnerMatch limits following symbolic links to those links that belong to the same owner as the link. Normally the Options directive specifies all the options: it doesn't merge the default options. The + sign indicates that the option specified should be added to the defaults.

After restarting with these parameters. If you don't define a virtual host, the server will access the main web pages (defined by the main DocumentRoot in entry /usr/local/etc/apache/access.conf).

Log file format

httpd logs accesses and errors to the files you specify. It's worth understanding what's inside them. The following example shows five log entries. Normally each entry is all on a very long line.

p50859b17.dip.t-dialin.net - -             name of system, more
[01/Nov/2002:07:06:12 +1030]               date of access
"GET /Images/yaoipower.jpeg HTTP/1.1"      HTML command
200                                        status (OK)
19365                                      length of data transfer

aceproxy3.acenet.net.au - -
[01/Nov/2002:07:35:34 +1030]
"GET /Images/randomgal.big.jpeg HTTP/1.0"
304 -                                      status (cached)

218.24.24.27 - -                           system without reverse DNS
[01/Nov/2002:07:39:55 +1030]
"GET /scripts/root.exe?/c+dir HTTP/1.0"    looking for an invalid file
404 284                                    status (not found)

218.24.24.27 - -
[01/Nov/2002:07:39:56 +1030]
"GET /MSADC/root.exe?/c+dir HTTP/1.0" 404 282

218.24.24.27 - -
[01/Nov/2002:07:39:56 +1030]
"GET /c/winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 292

218.24.24.27 - -
[01/Nov/2002:07:40:00 +1030]
"GET /_vti_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe?/c+dir HTTP/1.0"
404 323

The fields in the log file are separated by blanks, so empty entries are replaced by a - character. In this example, the second and third fields are always empty. They're used for identity checks and authorization.

To get the names of the clients, you need to specify the HostnameLookups on directive. This requires a DNS lookup for every access, which can be relatively slow.

Although we specified hostname lookups, the last four entries don't have any name: the system doesn't have reverse DNS. They come from a Microsoft machine infected with the Nimda virus and show an attempt to break into the web server. There's not much you can do about this virus; it will probably be years before it goes away. Apart from nuisance value, it has never posed any threat to apache servers.

Access control

Sometimes you want to restrict access to a web server, either for specific directories or for the web site as a whole. apache has a number of options to limit access. One possibility is to set options in /usr/local/etc/apache/httpd.conf to cover an individual host, but this is seldom useful. It's more likely that you will want to restrict access to specific directories, and it's easier to do that in the file .htaccess in the same directory.

For apache to even look at .htaccess, you need to change the configuration file, however: by default, it disables the use of .htaccess a together, as we saw above:

<Directory />
  Options FollowSymLinks
  AllowOverride None
</Directory>

For it to work, you'll have to change the AllowOverride parameter to some other value. There are five categories of entries that you can allow in .htaccess files:

AuthConfig allows .htaccess to include authorization directives.

FileInfo allows the use of directives controlling document types.

Indexes allows the use of directives controlling directory indexing.

Limit allows the use of directives controlling host access.

Options allows the use of directives controlling specific directory features.

You can find more details in /usr/local/share/doc/apache/manual/mod/core.html.

The most common use of the .htaccess is to require that users authorize themselves before accessing a directory. In this case, the browser will pop up a window like this:

(рис 25.1)

To achieve this, add something like this to your .htaccess file:

AuthType Basic
AuthName grog
AuthDBUserFile /usr/local/etc/apache/passwd
Require valid-user

This method is similar to normal login authentication. You need a password file, which you can create and update with dbmmanage:

# dbmmanage /usr/local/etc/apache/passwd adduser grog
New password:
Re-type new password:
User grog added with password encrypted to OzREW8Xx5hUAs using crypt
# dbmmanage /usr/local/etc/apache/passwd adduser guest
New password:
Re-type new password:
User guest added with password encrypted to hFCYwd23ftHE6 using crypt

This adds passwords for users grog and guest. The AuthName suggests a name to authenticate, but Require valid-user states that it can be any user. Even if you don't care which user logs in, you need to specify an AuthName line. If you do insist that only user grog can log in, you can write:

Require user grog

This will fail the authentication for any other user. You can also specify a list of users or groups. For example, you might add the following line:

AuthGroupFile /usr/local/etc/apache/group
Require group bigshots

/usr/local/etc/apache/group might then contain:

bigshots:  davidb davidp gordon grog liz malcolm

This will allow any of the users specified on this line to access the directory.

Apache modules

apache offers a large quantity of optional functionality, which it provides in the form of dynamically loadable modules. We've seen above that there are two long lists of module names in /usr/local/etc/apache/httpd.conf; the first starts with LoadModule and tells httpd which dynamic modules to load. The order is important; don't change it.

Proxy web servers

Apache is capable of operating as a proxy server: it can accept requests for web pages of other systems. This can be an alternative to a general IP aliasing package such as natd (see page 393) if you need it only for web access. It's also useful in conjunction with caching.

Unfortunately, by default the current version of Apache does not support proxy servers. You need to rebuild the package manually after enabling it in the configuration file. See the file INSTALL in the port build directory for more details. This file will be present after building Apache from source, and it will have a name like /usr/ports/www/apache13/work/apache1.3.23/src/INSTALL.Inaddition to reinstalling the server with code for proxy serving, you must set ProxyRequests to On to enable the proxy server.

Caching

One reason for enabling the proxy server is to cache data requests. Caching keeps pages requested through the proxy and presents them again if they are requested again. This is particularly useful if the server serves a large number of people who communicate with each other and are thus likely to request many of the same pages.

The Cache parameters are commented out by default. If you uncomment them, you should uncomment them all except possibly NoCache. When setting these values, change the name of the directory CacheRoot. A good name might be /usr/local/www/proxy.

Running apache

When you install apache, it installs the file /usr/local/etc/rc.d/apache.sh,which automatically starts apache at boot time. If you don't want to start it automatically, remove this file. You can start and stop apache manually with the apachectl program, which takes a command parameter:

# apachectl start       start httpd
# apachectl stop        stop httpd
# apachectl restart     restart httpd, or start if not running
# apachectl graceful    restart httpd "gracefully," or start if not running
# apachectl configtest  do a configuration syntax test

The difference between a normal and a "graceful" restart is that the graceful restart waits for existing connections to complete before restarting the individual server processes. Unless you're in a big hurry, use the graceful restart.

NFS server

A number of processes are needed to provide NFS server functionality:

The NFS daemon, nfsd, is the basic NFS server.

The mount daemon, mountd, processes mount requests from clients.

The NFS lockdaemon, rpc.lockd, processes lock requests for NFS file systems. There are still a lot of problems with this function on all platforms. It's best to avoid it if you can.

The status monitoring daemon, rpc.statd, provides a status monitoring service.

monitoring service.

In addition:

Since NFS uses Remote procedure calls (RPC), the rpcbind daemon must be running. rpcbind is not part of NFS, but it is required to map RPC port numbers to IP service numbers. In previous releases of FreeBSD, this function was performed by the portmap daemon. It has not been renamed, it has been replaced.

The server needs a file /etc/exports to define which file systems to export and how to export them. We'll look at this in the next section.

/etc/exports

A number of security implications are associated with NFS. Without some kind of authentication, you could mount any file system on the Internet. As a result, the security one file system per line.

NFS was developed at a time when users were relatively trusted. precautions are not overly sophisticated. /etc/exports describes the format is:

file system    options    systems

systems is a list of systems allowed to mount the file system. The only required field is the name of the file system, but if you're on the Internet, you should at least limit the number of systems that can mount your file systems. By default any system on the Net can mount your file systems.

There are a number of options. Here are the more important ones:

The -maproot option describes how to treat root. By default, root does not have special privileges on the remote system. Instead, NFS changes the user ID to user nobody, which is user 65534 (or -2). You can change this with the -maproot option. For example, to map root to the real root user for a specific file system, you would add -maproot=0 to the line describing the file system.

The -mapall option maps the user IDs of other users. This is relatively uncommon. See the man page exports(5) for more details.

The -ro option restricts access to read-only.

The –network option restricts the access to systems on the specified network.

The -alldirs option allows remote clients to mount any directory in the file system directly. Without this option, remote clients can only mount the root directory of the exported file system. We'll see an example where -alldirs can be of use during the discussion of diskless booting on page 543.

If you come from a System V background, you'll notice that the mechanism is different. /etc/exports corresponds in concept roughly to System V's /etc/dfs/dfstab file, except that the share statement does not exist.

Updating /etc/exports

To grant access to a file system, it's not enough to change the contents of /etc/exports: you also need to tell mountd that you have done so. You do this by the relatively common method of sending a hang up signal (SIGHUP) to mountd:

# killall -HUP mountd

A typical /etc/exports for presto might be:

/     -maproot=0            presto bumble wait gw
/usr  -maproot=0  -alldirs  -network 223.147.37.0

This allows root access to both file systems. Only the trusted systems presto, bumble, wait and gw are allowed to access the root file system, whereas any system on the local network may access /usr. Remote systems may mount any directory on the /usr file system directly.

Samba

BSD UNIX and the Internet grew up together, but it took other vendors a long time to accept the Internet Protocols. In that time, a number of other protocols arose. We've already mentioned X.25 and SNA, currently both not supported by FreeBSD. The protocols that grew up in the DOS world are more widespread, in particular Novell's IPX and Microsoft's Common Internet File System, or CIFS. CIFS was previously known as SMB (Server Message Block).

IPX support is relatively rudimentary. FreeBSD includes an IPX routing daemon, IPXrouted. See the man page IPXrouted(8) for further information. IPX is going out of use, so it's unlikely that support for it will improve. By contrast, Microsoft's CIFS is still alive and kicking. In the rest of this chapter we'll look at the standard implementation, Samba. This chapter describes only the FreeBSD side of the setup; you'll need to follow the Microsoft documentation for setting up the Microsoft side of the network.

you can get even more information, including support and a mailing list.

Samba includes a number of programs, most of which we don't touch on here. The ones we look at are:

smbd, a daemon that provides file and print services to SMB clients.

nmbd, which provides name services for NetBIOS.

smbpasswd, which sets up network passwords for Samba.

Smbclient, a simple ftp-like client that is useful for accessing SMB shared files on other servers, such as Windows for Workgroups. You can also use it to allow a UNIX box to print to a printer attached to any SMB server.

testparm, which tests the Samba configuration file, smb.conf.

smbstatus tells you who is using the smbd daemon.

Installing the Samba software

Install Samba from the port:

# cd /usr/ports/net/samba
# make install

This operation installs the Samba binaries in /usr/local/bin, the standard location for additional binaries on a BSD system, and the daemons smbd and nmbd in /usr/local/sbin. These locations are appropriate for FreeBSD, but they are not the locations that the Samba documentation recommends. It also installs the man pages in /usr/local/man, where the man program can find them. Finally, it installs a sample configuration file in /usr/local/etc/smb.conf.default. We'll look at how to configure Samba below.

There are a number of security implications for the server, since it handles sensitive data. To maintain an adequate security level,

Ensure that the software is readable by all and writeable only by root. smbd should be executable by all. Don't make it setuid. If an individual user runs it, it runs with their permissions.

Put server log files in a directory readable and writable only by root, since they may contain sensitive information.

Ensure that the smbd configuration file in /usr/local/etc/smb.conf is secured so that only root can change it.

The Samba documentation recommends setting the directory readable and writeable only by root. Depending on what other configuration files you have in /etc/local/etc, this could cause problems.

smbd and nmbd: the Samba daemons

The main component of Samba is smbd, the SMB daemon. In addition, you need the Samba name daemon, nmbd, which supplies NetBIOS name services for Samba. smbd requires a configuration file, which we'll look at below, while you don't normally need one for nmbd. By default, nmbd maps DNS host names (without the domain part) to NetBIOS names, though it can perform other functions if you need them. In this chapter we'll assume the default behaviour. See the man page nmbd(8) for other possibilities.

You have two choices of how to run smbd and nmbd: you can start them at boot time from /usr/local/etc/rc.d/samba.sh, or you can let inetd start them. The Samba team recommends starting them at boot time

When you install Samba from the Ports Collection, it installs a file /usr/local/etc/rc.d/samba.sh.sample .You just need to rename it to /usr/local/etc/rc.d/samba.sh. As the name suggests, it's a shell script. You can modify it if necessary, but it's usually not necessary.

The man page for smbd gives a number of parameters to specify the configuration file and the log file. As long as you stick to the specified file names, you shouldn't need to change anything: by default, smbd looks for the configuration file at /usr/local/etc/smb.conf, and this file contains the names of the other files.

Running the daemons from inetd

To run the daemons from inetd,

Edit /etc/inetd.conf. You should find the following two lines towards the bottom of the file with a # in front. Remove the # to show the lines as they are here. If your /etc/inetd.conf doesn't contain these lines, add them.

netbios-ssn  stream  tcp  nowait      root      /usr/local/sbin/smbd  smbd
netbios-ns   dgram   udp  wait        root      /usr/local/sbin/nmbd  nmbd
swat         stream  tcp  nowait/400  root      /usr/local/sbin/swat  swat

swat is an administration tool that we don't discuss here.

Either reboot, or send a HUP signal to cause inetd to re-read its configuration file:

# killall -1 inetd    send a SIGHUP

The configuration file

The Samba configuration file describes the services that the daemon offers. The port installs a sample configuration file in /usr/local/etc/smb.conf.default. You can use it as the basis of your own configuration file, which must be called /usr/local/etc/smb.conf: simply copy the file, and then edit it as described below.

The configuration file is divided into sections identified by a label in brackets. Most labels correspond to a service, but there are also three special labels: [global], [homes] and [printers], all of which are optional. We look at them in the following sections.

The [global] section

As the name suggests, the [global] section defines parameters that either apply to the server as a whole, or that are defaults for the other services. The interesting ones for us are:

The workgroup parameter defines the Microsoft workgroup to which this server belongs. Set it to match the Microsoft environment. In these examples, we'll assume:

workgroup = EXAMPLE

The printing entry specifies what kind of printer support Samba provides. Current versions of Samba support CUPS. If you are using CUPS (not described in this book), you don't need to do anything. Otherwise set:

printcap name = /etc/printcap
printing = bsd

guest account is the account (in UNIX terms: user ID) to use if no password is supplied. You probably want to define a guest account, since many Microsoft clients don't use user IDs. Ensure that the privileges are set appropriately. Alternatively, alter the parameter to point to an existing user.

Modern versions of Microsoft use a simple form of password encryption; older versions used none. Currently, Samba defaults to no encryption. Set encrypt passwords to yes.

Microsoft uses its own version of host name resolution, which doesn't involve DNS. Optionally, Samba will map Microsoft names to DNS. To enable this option, set dns proxy to yes.

By default, the log file is specified as /var/log/log. The text replaced by the name of the remote machine, so you get one log file per machine. Unfortunately, the name doesn't make it clear that this is a Samba log file. It's better to change this entry to:

log file = /var/log/samba.log.%m

socket options is hardly mentioned in the documentation, but it's very important: many Microsoft implementations of TCP/IP are inefficient and establish a new TCP connection more often than necessary. Select the socket options TCP_NODELAY and IPTOS_LOWDELAY, which can speed up the response time of such applications by over 95%.

The [homes] section

The [homes] section allows clients to connect to their home directories without needing an entry in the configuration file. If this section is present, and an incoming request specifies a service that is not defined in the configuration file, Samba checks if it matches a user ID. If it does, and if the specified password is correct, Samba creates a service that supplies the user's home directory.

The following options are of interest in the [homes] section:

writeable can be yes or no, and specifies whether the user is allowed to write to the directory.

create mode specifies the permission bits (in octal) to set for files that are created.

public specifies whether other users are allowed access to this directory. In combination with a guest user, this can be a serious security liability.

The [printers] section

The [printers] section describes printing services. It doesn't need the names of the printers: if it doesn't find the specified service, either in the configuration file or in the [homes] section, if it exists, it looks for them in the /etc/printcap file.

The Samba documentation claims that Samba can recognize BSD printing system automatically, but this is not always correct. Ensure that you have the following entries:

printing = bsd                      in the [global] sectionW
print command = lpr -r -P'%p' '%s'  in the [printers] sectionW

Note the printable option in the [printers] section: this is the option that distinguishes between printers ("yes")and file shares ("no").

Other sections: service descriptions

Samba takes any section name except for [global], [homes] or [printers] as the definition of a service. A typical example might be:

[ftp]
  comment = ftp server file area
  path = /var/spool/ftp/pub
  read only = yes
  public = yes
  write list = grog

This entry defines access to the anonymous ftp section. Anybody can read it, but only user grog can write to it.

Setting passwords

Samba uses a separate password file, /usr/local/private/secrets.tdb. To set up users, use the smbpasswd command, which copies the information from the system password file:

# smbpasswd -a grog
New SMB password:
Retype new SMB password:         as usual, no echo
Password changed for user grog.

Testing the installation

Once you have performed the steps described above, you can proceed to test the installation. First, run testparm to check the correctness of the configuration file:

$ testparm
Load smb config files from /usr/local/etc/smb.conf
Processing section "[homes]"
Processing section "[printers]"
Processing section "[ftp]"
Processing section "[src]"
Processing section "[grog]"
Loaded services file OK.
Press enter to see a dump of your service definitions    Press Enter

Global parameters:
lots of information which could be of use in debugging

[homes]
  comment = Home Directories
  read only = No

[printers]
  comment = All Printers
  path = /var/spool/samba
  guest ok = Yes
  printable = Yes
  browseable = No

[ftp]
  comment = ftp server file area
  path = /var/spool/ftp/pub
  write list = grog
  guest ok = Yes

[grog]
  path = /home/grog
  valid users = grog
  read only = No

As you see, testparm spells out all the parameters that have been created, whether explicitly or by default. If you run into problems, this is the first place to which to return.

Next, check that you can log in with smbclient. If you're running the servers as daemons, start them now. If you're starting them from inetd, you don't need to do anything.

$ smbclient -L freebie -U grog
added interface ip=223.147.37.1 bcast=223.147.37.255 nmask=255.255.255.0
Password:               as usual, no echo
Domain=[EXAMPLE]  OS=[Unix]  Server=[Samba 2.2.7a]

Sharename  Type  Comment
---------  ----  -------
homes      Disk  Home Directories
ftp        Disk  ftp server file area
grog       Disk
IPC$       IPC   IPC Service (Samba Server)
ADMIN$     Disk  IPC Service (Samba Server)

Server   Comment
------   -------
FREEBIE  Samba Server
PRESTO   Samba Server

Workgroup  Master
---------  ------
EXAMPLE    PRESTO

If you get this far, your password authentication is working. Finally, try to access the shares. Samba services are specified in Microsoft format: \\system\service. To make this worse, UNIX interprets the \ character specially, so you would need to repeat the character. For example, to access the ftp service on freebie, you would have to enter \\\\freebie\\ftp. Fortunately, smbclient understands UNIX-like names, so you can write //freebie/ftp instead.

To test, start smbclient from another system:

$ smbclient //freebie/ftp -U grog
added interface ip=223.147.37.1 bcast=223.147.37.255 nmask=255.255.255.0
Password:           as usual, no echo
Domain=[EXAMPLE] OS=[Unix] Server=[Samba 2.2.7a]
smb: \> ls
  .                               DR      0  Wed Jan 29 12:06:29 2003
  ..                               D      0  Sat Oct 26 10:36:29 2002
  instant-workstation-1.0.tar.gz       9952  Mon Mar 19 11:49:01 2001
xtset-1.0.tar.gz                       4239  Mon Aug  5 16:44:14 2002
gpart-0.1h.tbz.tgz                    27112  Tue Aug 27 10:07:59 2002

If you get this far, Samba is working. The next step is to attach to the services from the Microsoft machines. That's not a topic for this book. Note, however, that Samba only works with TCP/IP transport, not with NetBEUI.

Displaying Samba status

You can display the status of Samba connections with smbstatus. For example,

$ smbstatus
Samba version 2.2.7a
Service  uid   gid      pid    machine
--------------------------------------
ftp      grog  example  37390  freebie  (223.147.37.1) Mon Mar 31 13:48:13 2003

No locked files

Страницы:

Server daemons for basic services
Client	Server
ssh	sshd
telnet	telnetd
sftp	sftp-server
ftp	ftpd
rsync	rsyncd
(browser)	httpd
(NFS)	nfsd

In addition to these servers, we look at a few others in other chapters:

We've already looked at Xservers briefly in Chapter 8, Taking control, and we'll see more in Chapter 28, XFree86 in depth.

Chapter 21 discussed DNS name servers.

Chapter 27 discusses Mail Transport Agents or MTAs, also referred to as mail servers.

Running servers from inetd

At startup, inetd reads a configuration file /etc/inetd.conf to determine which ports to monitor and what to do when a message comes in. Here's an excerpt:

#$FreeBSD: src/etc/inetd.conf,v 1.58 2002/08/09 17:34:13 gordon Exp $ #
#Internet server configuration database
#
#ftp     stream  tcp   nowait  root  /usr/libexec/lukemftpd  ftpd -l -r
#ftp     stream  tcp   nowait  root  /usr/libexec/ftpd       ftpd -l
#ftp     stream  tcp6  nowait  root  /usr/libexec/ftpd       ftpd -l
#telnet  stream  tcp   nowait  root  /usr/libexec/telnetd    telnetd
#telnet  stream  tcp6  nowait  root  /usr/libexec/telnetd    telnetd
#shell   stream  tcp   nowait  root  /usr/libexec/rshd       rshd
#shell   stream  tcp6  nowait  root  /usr/libexec/rshd       rshd
#login   stream  tcp   nowait  root  /usr/libexec/rlogind    rlogind
#login   stream  tcp6  nowait  root  /usr/libexec/rlogind    rlogind
#exec    stream  tcp   nowait  root  /usr/libexec/rexecd     rexecd
#shell   stream  tcp6  nowait  root  /usr/libexec/rshd       rshd

This file has the following format:

Unable to connect to remote host: Connection refused

The next column specifies the user as which the function should be performed.

All remaining columns are the parameters to be passed to the daemon.

inetd_enable="YES"  # Run the network daemon dispatcher (YES/NO).

The other daemons are not mentioned in /etc/inetd.conf:

sftp-server is the server for sftp. It gets started from sshd.

rsync stream tcp nowait root /usr/local/bin/rsync rsync –daemon

The name rsync is not a typo. rsync and rsyncd are the same thing; it's the --daemon option that makes rsync run as a daemon.

inetd doesn't notice alterations to /etc/inetd.conf automatically. After modifying the file, you must send it a SIGHUP signal:

# killall -HUP inetd

You can write -1 instead of -HUP. This causes inetd to re-read /etc/inetd.conf.

Configuring ftpd

Normally you'll run ftpd from inetd, as we saw above. If you want to run it directly, perform the following steps:

Add the following line in /etc/rc.local:

echo -n 'starting local daemons:' #put your local stuff here echo " ftpd"  ftpd -D

The option -D tells ftpd to run as a daemon. You will possibly want other options as well; see the discussion below.

Comment out the ftp line in /etc/inetd.conf by adding a hash mark (#) in front of it:

#  ftp  stream   tcp  nowait  root  /usr/libexec/ftpd  ftpd -l

Either reboot, or cause inetd to re-read its configuration file:

#  killall -1 inetd  send a SIGHUP

If you don't perform this step, inetd keeps the ftp port open, and ftpd can't run.

For security reasons, you will probably want to add options such as logging and anonymous ftp. We'll look at how to do that in the next two sections.

anonymous ftp

Anonymous ftp gives you a couple of security options:

It restricts access to the machine generally: the user doesn't learn any passwords, so he has no other access to the machine.

In addition, you can start ftpd in such a manner that it will allow only anonymous ftp connections.

There are a number of preparations for anonymous ftp:

Decide on a directory for storing anonymous ftp files. The location will depend on the amount of data you propose to store there. By default, it's /var/spool/ftp.

Set the ownership of the directories like this:

dr-xr-xr-x     2 ftp     ftp  512 Feb 28 12:57 bin
drwxrwxrwx     2 ftp     ftp  512 Oct   7 05:55 incoming
drwxrwxr-x   20 ftp     ftp  512 Jun   3 14:03 pub

This enables read access to the pub directory and read-write access to the incoming subdirectory.

d--x--x-- x  20 ftp    ftp  512 Jun  314:03 pub

This allows access to the files, but not to the directory, so the remote user can't find the names of the files in the directory.

Restricting access and logging

A number of ftpd options make it easier to control and monitor ftp access:

The -l option logs each session, whether successful or not, to syslogd with the facility LOG_FTP. To enable this logging, your /etc/syslog.conf should contain a line like

ftp.*      /var/log/ftpd

In addition, the file /var/log/ftpd must exist. If it doesn't, create it with:

# touch /var/log/ftpd

The -l option has two levels: if you specify it once, it logs connections only. If you specify it twice, it also lists the files that are transferred.

The -S option logs all anonymous transfers to the file /var/log/ftpd.

You can restrict access to only anonymous ftp with the -A option.

There are a number of other options; see the man page ftpd(8) for further details.

Log file format

The format of the log files is a little unusual. You'll see things like:

Oct 12 16:32:04 freebie ftpd[8691]: ANONYMOUS FTP LOGIN FROM adam.adonai.net, leec@a donainet
Oct 12 18:33:32 freebie ftpd[9007]: connection from gateway.smith.net.au
Oct 12 18:33:37 freebie ftpd[9007]: ANONYMOUS FTP LOGIN FROM gateway.smith.net.au, m
ike
Oct 12 21:36:28 freebie ftpd[9369]: connection from grisu.bik-gmbh.de
Oct 12 21:36:29 freebie ftpd[9369]: ANONYMOUS FTP LOGIN FROM grisu.bik-gmbh.de, harv
est@
Oct 12 21:36:37 1997!harvest@!grisu.bik-gmbh.de!/pub/cfbsd/README!9228!1 
Oct 12 21:37:05 freebie ftpd[9371]: connection from grisu.bik-gmbh.de
Oct 12 21:37:06 freebie ftpd[9371]: ANONYMOUS FTP LOGIN FROM grisu.bik-gmbh.de, harv
est@
Oct 13 09:38:19 freebie ftpd[13514]: connection from 151.197.101.46
Oct 13 09:38:21 freebie ftpd[13514]: ANONYMOUS FTP LOGIN FROM 151.197.101.46, bmc@ho
vercraft.willscreek.com
Oct 13 09:38:58 1997!bmc@hovercraft.willscreek.com!151.197.101.46!/pub/cfbsd/dear-re viewer!8890!1
Oct 13 09:41:42 1997!bmc@hovercraft.willscreek.com!151.197.101.46!/pub/cfbsd/txt/26-netdebug.txt.gz!12188!1
Oct 13 09:42:05 1997!bmc@hovercraft.willscreek.com!151.197.101.46!/pub/cfbsd/txt/C-p ackages.txt.gz!37951!1
Oct 13 09:59:07 freebie ftpd[14117]: connection from 151.197.101.46
Oct 13 09:59:08 freebie ftpd[14117]: ANONYMOUS FTP LOGIN FROM 151.197.101.46, bmc@ho vercraft.willscreek.com
Oct 13 09:59:24 1997!bmc@hovercraft.willscreek.com!151.197.101.46!/pub/cfbsd/txt/D-b iblio.txt.gz!1815!1

This log excerpt shows three kinds of message:

The lines full of ! marks show files being transferred. The ! marks delimit the fields, which are:

The year, as an extension of the timestamp.

The user ID.

The IP address of the system to which the data is transferred.

The name of the file transferred.

The number of bytes transferred.

Running sshd

Normally you start sshd from the system configuration file /etc/rc.conf:

sshd_enable="YES"  # Enable sshd

That's all you need to do for sshd. You can also start it simply with:

#sshd

When PermitRootLogin is set to yes, you can log in as root via ssh. Normally it's disabled.

Set PasswordAuthentication to no if you want all access to be via key exchange (see page 420 for more details).

If you want to run sftp-server, add the following line to /etc/ssh/sshd_config:

Subsystem  sftp /usr/libexec/sftp-server

It should be present by default.

rsyncd

Starting rsyncd isn't enough, though: it needs configuration. Create a file /usr/local/etc/rsyncd.conf with contents something like this:

motd file = /usr/local/etc/rsyncd.txt
log file = /var/log/rsyncd.log
transfer logging = true
[groggy]
    path = /home/grog/public_html
    uid = grog
    read only = yes
    list = yes
    comment = Greg's web pages
    hosts allow = 223.147.37.0/24
[tivo]
    path = /var/tivo
    uid = grog
    read only = no
    list = yes
    comment = TiVo staging area
    hosts allow = tivo.example.org

2002/10/24 13:31:49 [16398] send presto.example.org [192.109.197.74] groggy () slash
dot/topicscience.gif 1083
2002/10/24 13:31:49 [16398] send presto.example.org [192.109.197.74] groggy () slash
dot/topicsecurity.gif 3034
2002/10/24 13:31:49 [16398] send presto.example.org [192.109.197.74] groggy () slash
dot/topictv.jpg 951
2002/10/24 13:31:49 [16398] send presto.example.org [192.109.197.74] groggy () slide
.pdf 40470
2002/10/24 13:31:49 [16398] send presto.example.org [192.109.197.74] groggy () stock
whip.html 1602

Module . Again rsyncd accesses the data as user grog.

There are a large number of other options for rsyncd, but this example shows the most important ones. See the man page rsyncd.conf(5) for more information.

Setting up a web server

# cd /usr/ports/www/apache13
# make install

# cd /usr/local/www/data
# ln -s /usr/local/share/doc/apache/manual apachedoc

After this, you can access the documentation at (for example) http://www.example.org/apachedoc/.

Configuring apache

The Apache port uses the following directories:

The configuration files are in the directory hierarchy /usr/local/etc/apache. The port installs prototype configuration files, but they need to be modified.

Icons for Apache's own use are stored in /usr/local/www/icons. You can't access these icons by URI, so don't put your own images here.

CGI scripts are stored in /usr/local/www/cgi-bin.

The configuration file

httpd.conf

ServerType states whether you start it from inetd or standalone (the default). It's not a good idea to start httpd from inetd, so you should leave this entry unchanged.

ServerRoot claims to be the path to the configuration files, but in fact the files are stored in the subdirectory etc/apache of this directory. You shouldn't need to change it.

The comments about ScoreBoardFile suggest that you should check to see if the system creates one. Don't bother: FreeBSD doesn't create this file, and you don't need to worry about it.

The next area of interest is a large list of modules. A lot of apache functionality is optional, and you include it by including a module. We'll look at this in more detail below.

The parameter ProxyRequests allows Apache to function as a proxy server. We'll look at this in more detail below.

The parameters starting with Cache apply only to proxy servers, so we'll look at them below as well.

The Listen parameter defines alternate ports on which Apache listens.

Virtual hosts

There's a good reason to keep the "main" server information: it serves as defaults for all virtual hosts, which can make the job of adding a virtual host a lot easier.

<VirtualHost *>
ServerAdmin grog@example.org
DocumentRoot /usr/local/www/biguser      Where we put the web pages
ServerName www.biguser.com               the name that the server will claim to be
ServerAlias biguser.com                  alternative server name
ErrorLog /var/log/biguser/error_log
TransferLog /var/log/biguser/access_log
Options +FollowSymLinks
Options +SymLinksIfOwnerMatch
</VirtualHost>

Next you can put information about individual data directories. The default server first supplies defaults for all directories:

<Directory />
  Options FollowSymLinks
  AllowOverride None
</Directory>

There's a separate entry for the data hierarchy:

<Directory "/usr/local/www/data">
  Options Indexes FollowSymLinks MultiViews
  AllowOverride None
  Order allow,deny
  Allow from all
</Directory>

In this case, we have two additional options:

MultiViews allows content-based multiviews, which we don't discuss here.

Note that if you change the name of the default data directory, you should also change the name on the Directory invocation.

We'll look at the remaining entries in more detail when we see them again in the discussion of the .htaccess file.

httpd can maintain two log files, an access log and an error log. We'll look at them in the next section. It's a good idea to keep separate log files for each domain.

For the same reason, it's a good idea to have a and http://biguser.com.

Log file format

httpd logs accesses and errors to the files you specify. It's worth understanding what's inside them. The following example shows five log entries. Normally each entry is all on a very long line.

p50859b17.dip.t-dialin.net - -             name of system, more
[01/Nov/2002:07:06:12 +1030]               date of access
"GET /Images/yaoipower.jpeg HTTP/1.1"      HTML command
200                                        status (OK)
19365                                      length of data transfer

aceproxy3.acenet.net.au - -
[01/Nov/2002:07:35:34 +1030]
"GET /Images/randomgal.big.jpeg HTTP/1.0"
304 -                                      status (cached)

218.24.24.27 - -                           system without reverse DNS
[01/Nov/2002:07:39:55 +1030]
"GET /scripts/root.exe?/c+dir HTTP/1.0"    looking for an invalid file
404 284                                    status (not found)

218.24.24.27 - -
[01/Nov/2002:07:39:56 +1030]
"GET /MSADC/root.exe?/c+dir HTTP/1.0" 404 282

218.24.24.27 - -
[01/Nov/2002:07:39:56 +1030]
"GET /c/winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 292

218.24.24.27 - -
[01/Nov/2002:07:40:00 +1030]
"GET /_vti_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe?/c+dir HTTP/1.0"
404 323

To get the names of the clients, you need to specify the HostnameLookups on directive. This requires a DNS lookup for every access, which can be relatively slow.

Access control

For apache to even look at .htaccess, you need to change the configuration file, however: by default, it disables the use of .htaccess a together, as we saw above:

<Directory />
  Options FollowSymLinks
  AllowOverride None
</Directory>