A Comprehensive Guide to FreeBSD
This is a Comprehensive Guide to Setting up a FreeBSD Server.
If you have any questions that you don't see addressed by this page. Please send any comments to fbsd-book@vmunix.com
:A network interface is a device that allows you to communicate with your network. These devices could be a network card, or a modem, or a variety of different pieces of equipment that allows communication. These devices need to be configured so that the network knows who you are. These interfaces will be configured to use TCP/IP networking protocols. This is usually setup in the /etc/rc.conf, or /etc/sysconfig if you have a 2.2.1 or older system.
TCP/IP is the protocol used for network communications by FreeBSD. Of course, TCP/IP is also the protocol used to communicate over the Internet, meaning FreeBSD can be used on the Internet ``out of the box''. This chapter will attempt to give you a brief overview of the TCP/IP protocol, and what you need to understand in order to configure your FreeBSD machine for use on a TCP/IP network.
While we are going to give you enough of an introduction to TCP/IP in this book to get you up and running, if you're in the position of maintaining a FreeBSD network (or any TCP/IP network for that matter) you'll almost certainly need a better understanding of the TCP/IP protocol. TCP/IP is a large enough protocol that one could devote an entire book to it, and indeed many people have! An excellent book on the subject (IMHO) is TCP/IP Network Administration by Craig Hunt. Published by O'Reilly and Associates. This book gives a more in depth overview of TCP/IP and covers many of the common Unix services that we touch upon in this book. While the material is somewhat out of date when it concerns configuration files and so on, you'll find that the concepts are still perfectly conveyed. If you're interested in the guts of the protocol itself, Richard Stevens has three entire volumes written about TCP/IP starting with the theoretical and moving towards more practical knowledge. TCP/IP Illustrated is published by Addison Wesley.
Note: Although FreeBSD can also use the Apple-talk and IPX/SPX (Novell) protocols, this isn't the norm and for this reason we'll focus on TCP/IP as the protocol of choice for FreeBSD. The Applications section of this book will look at using FreeBSD as a replacement Apple and Novell File/Print server - we'll discuss how to turn on the appropriate protocols there. |
The first thing you need to know about TCP/IP is that it is actually a suite of protocols. Together, this suite of protocols lets us send data from one computer to another -- a source to a destination -- without having to specifically know the exact path the data will take on its journey. There are three important components that you need to know: IP, TCP, and UDP.
Essentially, IP makes packets. What's a packet? A packet is a small ``unit'', or ``package'' of data. The easiest way to understand what a packet is, and how IP makes packets, is to look at an example. Let's say you have a 200K file you wish to send over the Internet to a friend. You can think of this file as a ``stream'' of data - the file has a beginning, and a sequential set of bytes (200 thousand of them in this case) all the way up to the end of the file. Any continuous set of data like this is called a stream, due to the directional nature of the data. The most important thing to realize about a data stream is that the order that the bytes are in is critical. What IP does is break this continuous stream of data up into discrete packages (``packets'') that can be delivered independently. IP chops this data stream up into packets, wraps each packet to make it suitable for delivery over the Internet, and labels the packet with a source and destination address.
What I didn't tell you before about IP is that, oddly enough, IP is not reliable. IP doesn't guarantee that a packet will reach its destination, or that a collection of packets that represent a single coherent data stream will arrive in the correct sequential order. That's where TCP comes in. TCP puts the packets in their correct order and makes sure all the packets arrived at the destination. Without TCP, IP would be nearly useless! I guess that's why they call the suite TCP/IP!! :-)
Hidden in the address information of each packet is a sequence number. IP increments the sequence number as it sends each packet out, and TCP uses these sequence numbers to reassemble the packets in the correct order when they arrive at the destination. TCP also uses the sequence number to determine if any packets are missing. If a particular packet does not show up (it was incorrectly routed, etc.) TCP requests the packet from the source again. It will keep trying until it has all the packets that make up a data stream. Hence, TCP makes the TCP/IP packet delivery mechanism ``reliable''.
TCP adds another layer of functionality that IP itself doesn't provide: ports. IP numbers specify individual computers on the network, whereas TCP port numbers specify services on that particular computer. Port numbers allow you to have many services running at once, and have a mechanism for making sure requests get to the correct service. The example you are perhaps most familiar with is a web server. WWW servers typically run on port 80. The standard notation for representing a IP number and Port number combination is ip:port - for example, 192.168.1.100:80 . TCP lets us send a packet intended for the web server, and a packet intended for the telnet server (port 23) to the same host IP number simultaneously. Great! For the record, port numbers range from 0 - 65000. All ports below 1024 are restricted, meaning that only root has the privilege of starting a service which listens on a port less than 1024. Anything above 1024 is fair game for any user process to use - no root privileges are required.
As we discovered earlier, a FreeBSD system can run many programs simultaneously - such is the case for a FreeBSD network server; it will run a program for each service you wish to provide. The problem is, each service eats up a chunk of memory - and memory is always in demand (not to mention expensive!). The solution is to only start a service when it has a pending request, and to terminate it when a reply is sent to the client making the request. So how does a service know when to wake up?
That's where inetd comes in. It's called the Internet ``super-server'' since it controls many of the Internet services available on a typical Unix host. inetd monitors the port numbers of all requests that come to a server. When a request comes in, inetd looks in /etc/services for the name of the service. As we can see below, the services file is a simple mapping of port numbers to service names:
Next, after inetd has the name of the service to start, it looks in its configuration file, /etc/inetd.conf to get setup information. The config file looks like this:
The general format of the file is as follows:
service name
socket type
protocol
{wait|nowait}[/max-child]
user
server program
server program arguments
Let's take a closer look at one of the lines and see what this all means.
telnet stream tcp nowait root /usr/libexec/telnetd telnetd
The first field, telnet, is the name of the service. This name must match exactly the name found in /etc/services. The second and third fields, stream tcp, describes the kind of connection the service will make. In this case, tcp will handle the packet ordering so that the downloaded information appears to be a steady stream of error-free data. The only other option for this field, dgram udp, specifies that UDP, not TCP, will handle the packet ordering (the so called ``unreliable'' datagram form of TCP/IP).
The fourth field, nowait tells the service to spawn itself for each service request that comes to the server - even if one instance of the program is already running. The other option, wait says to run the programs sequentially, waiting for the first program to finish before staring up another instance.
The fifth field, root, specifies the user ID used to run the service. The majority of programs started from inetd run as the user ``root'' or ``nobody'' The remaining fields tell inetd where to find the program, and any arguments that are required (in the case of telnet, no arguments are present).
Sidebar: The disadvantage of running programs through inetd is that it isn't too efficient for services that are constantly being run, perhaps once a second, or even hundreds of times per second. Why is that you ask? Well, although running a program through inetd generally reduces the amount of memory used, it introduces a penalty in that it must ``fork'' the program each time a request comes in. ``fork'' simply means that inetd starts a new process for the service. We won't get into the technical details of the overhead required to fork a process. Let's just say that there is an overhead, and under a busy system is enough to cause a considerable slow down. For this reason, some services are run as ``daemons'' instead of through inetd. How you decide to run a service depends entirely on what you feel is important. If performance is critical, run the program as a daemon. If you want to reduce memory usage, run the program through the inetd super-server. Typically, FTP, finger, talk, POP3, and telnetd are run through the inetd server, but things such as web servers and the mail delivery server (sendmail, usually) are run as daemons. Web servers like the NCSA and Apache servers even go through the trouble of ``pre-forking'' several copies of themselves to eliminate the overhead of forking under large numbers of requests! If you install a new service, the documentation that comes with the program will generally give tips on which approach is best for that particular application. |
Not Yet Scheduled
Not Yet Scheduled
Not Yet Scheduled
if you are installing from the ports it installs everything to /usr/local/samba/ The binary files are stored in the bin directory. The config file is located in lib/smb.conf
if you are installing from a package it installs stuff to /usr/local/sbin and the config file is in /usr/local/etc/smb.conf You will need to read the man page on smb.conf to understand how to create the smb.conf configuration file. The Documentation on smb.conf is extremely well written and comprehensive. Everything you could possibly put in the configuration file is included in that man page. To read it, type:
man smb.conf
Use testparm to check your config file. testparm will also tell you where Samba is looking for your default config file.
No matter which way you installed samba, you will need to modify your /etc/rc.local file to start Samba at boot up. To do this, include these lines in yourrc.local file:
/usr/local/sbin/smbd -D /usr/local/sbin/nmbd -D
Not Yet Scheduled
First off you have to have a valid domain name to use. The place that your domain is registered with needs to point at the IP address of your primary DNS Machine. This should all be taken care of by INTERNIC or the DNS one level above you.
If you are setting up a sub-domain, you will need to create a mapping in your zone pointing to the primary DNS for that domain.
First:
In the /etc/sysconfig file, or in the new /etc/rc.conf, Add the line:
namedflags="-b /etc/namedb/named.boot"
This will start the ``Name Daemon'' at boot up and set it to read the file /etc/namedb/named.boot as the configuration file.
Now you need to cd to the /etc/namedb/ directory.
Now type:
sh make-localhost
This will create the localhost.rev in that directory. This file is necessary for all local traffic to be properly dealt with.
Now create or edit the file named.boot
++++++++++++++NAMED.BOOT EXAMPLE ++++++++++++++++++++ ;semi colons comment out statments. ; sortlist 128.3.0.0 ; The sort list gives higher priority to certain domains in the case ;of multi-homed hosts. directory /etc/namedb ; this denotes the directory that named should look to find all of the ; source files. ; type domain source host/file backup file cache . named.root ; named keeps a cache of recently looked up hostname in the file mentioned. primary 0.0.127.IN-ADDR.ARPA localhost.rev ; this is the local host entry needs to be there. Usually automatic. primary Berkeley.EDU your.domain.zone primary 32.128.IN-ADDR.ARPA your.domain.rev ; These lines are a pair. They represent the primary domain you control ; The first one is your domain and the second is the reverse lookup table. ; You need to have each DNS entry entered in to both files. ; You will need a pair of primary lines for each primary domain that ; you administer. secondary Berkeley.EDU 128.32.130.11 128.32.133.1 ucbhosts.bak secondary 32.128.IN-ADDR.ARPA 128.32.130.11 128.32.133.1 ucbhosts.rev.bak ; These lines are a pair also. They represent the domains that you are ; interested in knowing about if their DNS goes down. Or you may just be ; the back up DNS for them. ; Instead of source files, you specify the host that is the primary DNS ; for that domain. You must also specify that filename that named will ; store the temporary table in. ; You need a pair of these lines for each of the Domains that you are ; a secondary DNS for. ++++++++++++++++++++++End Example Named.boot File++++++++++++++++++
If you had the domain ``my.domain.com'', the IP Address range 10.20.40.0 - 10.20.40.255, and wanted to be the primary DNS for it, you would put this line in your named.boot file:
primary my.domain.com my.domain.com.zone
primary 40.20.10.IN-ADDR.ARPA my.domain.com.rev
Now you have to make the primary source file. Create a file called /etc/named/your.domain.zone Substitute you actual domain name. It must match the filename specified in the primary entry of named.boot
Here is an example of such a file.
IN soa bbcc.ctc.edu. root.bbcc.ctc.edu. (
28 ;serial
10800 ;refresh every 3 hours
900 ;retry every 15 minutes
604800 ;expire after a week
86400 ;minimum of a day
)
IN NS bbcc.ctc.edu.
IN NS ctc.ctc.edu.
IN NS bb.cc.wa.us.
bbcc.ctc.edu. IN A 134.39.180.254
mail IN CNAME bbcc.ctc.edu.
www IN CNAME bbcc.ctc.edu.
irc IN CNAME bbcc.ctc.edu.
bigbend.ctc.edu. IN CNAME bbcc.ctc.edu.
athena IN A 134.39.180.5
IN HINFO intel 586-133 winnt
proto IN A 134.39.180.6
aries IN CNAME bb.cc.wa.us.
sal IN A 134.39.180.8
dialup3 IN A 134.39.180.252
;end of file.
5) Now you have to make the primary reverse lookup file. Create a file called /etc/named/your.domain.rev
Substitute your actual domain name. It must match the filename specified in the primary entry of named.boot
Here is an example of such a file.
IN soa bbcc.ctc.edu. root.bbcc.ctc.edu. ( 28 ;serial 10800 ;refresh every 3 hours 900 ;retry every 15 minutes 604800 ;expire after a week 86400 ;minimum of a day ) 8 IN PTR sal.bbcc.ctc.edu. 252 IN PTR dialup.bbcc.ctc.edu.
Not Yet Scheduled
Not Yet Scheduled
After you have installed IpFilter: You will need to change three files:
/etc/rc.local
/etc/sysconfig
/etc/natrules
This was tested using ipfilter 3.1.4 and FreeBSD 2.1.6-RELEASE
If you are using a Kernel Loadable Module you need to edit your /etc/rc.local file and load the module at boot time.
use the line:
modload /lkm/if_ipl.o
If you are not loading a kernel module, skip this step.
Make a file called /etc/natrules put in the rules that you need for your system. If you want to use the whole 10 Network. Try:
map fxp0 10.0.0.0/8 -> 208.8.0.1/32 portmap tcp/udp 10000:65000
Here is an explanation of each part of the command:
map starts the command.
fxp0 is the interface with the real internet address.
10.0.0.0 is the subnet you want to use.
/8 is the subnet mask. ie 255.0.0.0
208.8.0.1 is the real IP address that you use.
/32 is the subnet mask 255.255.255.255, ie only use this IP address.
portmap tcp/udp 10000:65000
tells it to use the ports to redirect the tcp/udp calls through The one line should work for the whole network.
The NAT Rules will need to be loaded every time the computer
reboots.
In your /etc/rc.local put the line:
ipnat -f /etc/natrules
To check and see if it is loaded, as root type:
ipnat -ls
Tell the kernel to route these addresses. In the /etc/rc.conf put the line:
Gateway=YES
Or configure it by had by putting this line in the /etc/rc.local file :
sysctl -w net.inet.ip.forwarding=1
Now you have to add a static routes for the subnet ranges. Edit your /etc/rc.conf, or on an older system, your /etc/sysconfig to add them at bootup.
static_routes="foo"
route_foo="10.0.0.0 -netmask 0xf0000000 -interface 10.0.0.1"
I have two Intel Ether Express Pro B cards. One is on 208.8.0.1 The other is on 10.0.0.1 You need to configure these in the /etc/sysconfig
network_interfaces="fxp0 fxp1" ifconfig_fxp0="inet 208.8.0.1 netmask 255.255.255.0" ifconfig_fxp1="inet 10.0.0.1 netmask 255.0.0.0"
Note: When using ftp from a client computer on the virtual network, you will need to use passive mode. Otherwise, it will time out trying to get a directory listing. |