Κεφάλαιο 29. Εξυπηρετητές Δικτύου

inetd(8) is sometimes referred to as the "Internet Super-Server" because it manages connections for several services. When a connection is received by inetd, it determines which program the connection is destined for, spawns the particular process and delegates the socket to it (the program is invoked with the service socket as its standard input, output and error descriptors). Running inetd for servers that are not heavily used can reduce the overall system load, when compared to running each daemon individually in stand-alone mode.

Primarily, inetd is used to spawn other daemons, but several trivial protocols are handled directly, such as chargen, auth, and daytime.

This section will cover the basics in configuring inetd through its command-line options and its configuration file, /etc/inetd.conf.

inetd is initialized through the rc(8) system. The inetd_enable option is set to NO by default, but may be turned on by sysinstall during installation, depending on the configuration chosen by the user. Placing:

or

into /etc/rc.conf will enable or disable inetd starting at boot time. The command:

can be run to display the current effective setting.

Additionally, different command-line options can be passed to inetd via the inetd_flags option.

Like most server daemons, inetd has a number of options that it can be passed in order to modify its behaviour. The full list of options reads:

inetd [-d] [-l] [-w] [-W] [-c maximum] [-C rate] [-a address | hostname] [-p filename] [-R rate] [-s maximum] [configuration file]

Options can be passed to inetd using the inetd_flags option in /etc/rc.conf. By default, inetd_flags is set to -wW -C 60, which turns on TCP wrapping for inetd’s services, and prevents any single IP address from requesting any service more than 60 times in any given minute.

Novice users may be pleased to note that these parameters usually do not need to be modified, although we mention the rate-limiting options below as they be useful should you find that you are receiving an excessive amount of connections. A full list of options can be found in the inetd(8) manual.

Configuration of inetd is done via the file /etc/inetd.conf.

When a modification is made to /etc/inetd.conf, inetd can be forced to re-read its configuration file by running the command:

Each line of the configuration file specifies an individual daemon. Comments in the file are preceded by a "#". The format of each entry in /etc/inetd.conf is as follows:

An example entry for the ftpd(8) daemon using IPv4 might read:

Depending on the choices made at install time, many of inetd’s services may be enabled by default. If there is no apparent need for a particular daemon, consider disabling it. Place a "#" in front of the daemon in question in /etc/inetd.conf, and then reload the inetd configuration. Some daemons, such as fingerd, may not be desired at all because they provide information that may be useful to an attacker.

Some daemons are not security-conscious and have long, or non-existent, timeouts for connection attempts. This allows an attacker to slowly send connections to a particular daemon, thus saturating available resources. It may be a good idea to place max-connections-per-ip-per-minute, max-child or max-child-per-ip limitations on certain daemons if you find that you have too many connections.

By default, TCP wrapping is turned on. Consult the hosts_access(5) manual page for more information on placing TCP restrictions on various inetd invoked daemons.

daytime, time, echo, discard, chargen, and auth are all internally provided services of inetd.

The auth service provides identity network services, and is configurable to a certain degree, whilst the others are simply on or off.

Consult the inetd(8) manual page for more in-depth information.

NFS consists of at least two main parts: a server and one or more clients. The client remotely accesses the data that is stored on the server machine. In order for this to function properly a few processes have to be configured and running.

The server has to be running the following daemons:

The client can also run a daemon, known as nfsiod. The nfsiod daemon services the requests from the NFS server. This is optional, and improves performance, but is not required for normal and correct operation. See the nfsiod(8) manual page for more information.

NFS configuration is a relatively straightforward process. The processes that need to be running can all start at boot time with a few modifications to your /etc/rc.conf file.

On the NFS server, make sure that the following options are configured in the /etc/rc.conf file:

mountd runs automatically whenever the NFS server is enabled.

On the client, make sure this option is present in /etc/rc.conf:

The /etc/exports file specifies which file systems NFS should export (sometimes referred to as "share"). Each line in /etc/exports specifies a file system to be exported and which machines have access to that file system. Along with what machines have access to that file system, access options may also be specified. There are many such options that can be used in this file but only a few will be mentioned here. You can easily discover other options by reading over the exports(5) manual page.

Here are a few example /etc/exports entries:

The following examples give an idea of how to export file systems, although the settings may be different depending on your environment and network configuration. For instance, to export the /cdrom directory to three example machines that have the same domain name as the server (hence the lack of a domain name for each) or have entries in your /etc/hosts file. The -ro flag makes the exported file system read-only. With this flag, the remote system will not be able to write any changes to the exported file system.

The following line exports /home to three hosts by IP address. This is a useful setup if you have a private network without a DNS server configured. Optionally the /etc/hosts file could be configured for internal hostnames; please review hosts(5) for more information. The -alldirs flag allows the subdirectories to be mount points. In other words, it will not mount the subdirectories but permit the client to mount only the directories that are required or needed.

The following line exports /a so that two clients from different domains may access the file system. The -maproot=root flag allows the root user on the remote system to write data on the exported file system as root. If the -maproot=root flag is not specified, then even if a user has root access on the remote system, he will not be able to modify files on the exported file system.

In order for a client to access an exported file system, the client must have permission to do so. Make sure the client is listed in your /etc/exports file.

In /etc/exports, each line represents the export information for one file system to one host. A remote host can only be specified once per file system, and may only have one default entry. For example, assume that /usr is a single file system. The following /etc/exports would be invalid:

One file system, /usr, has two lines specifying exports to the same host, client. The correct format for this situation is:

The properties of one file system exported to a given host must all occur on one line. Lines without a client specified are treated as a single host. This limits how you can export file systems, but for most people this is not an issue.

The following is an example of a valid export list, where /usr and /exports are local file systems:

The mountd daemon must be forced to recheck the /etc/exports file whenever it has been modified, so the changes can take effect. This can be accomplished either by sending a HUP signal to the running daemon:

or by invoking the mountd rc(8) script with the appropriate parameter:

Please refer to Χρησιμοποιώντας Το Σύστημα rc Στο FreeBSD for more information about using rc scripts.

Alternatively, a reboot will make FreeBSD set everything up properly. A reboot is not necessary though. Executing the following commands as root should start everything up.

On the NFS server:

On the NFS client:

Now everything should be ready to actually mount a remote file system. In these examples the server’s name will be server and the client’s name will be client. If you only want to temporarily mount a remote file system or would rather test the configuration, just execute a command like this as root on the client:

This will mount the /home directory on the server at /mnt on the client. If everything is set up correctly you should be able to enter /mnt on the client and see all the files that are on the server.

If you want to automatically mount a remote file system each time the computer boots, add the file system to the /etc/fstab file. Here is an example:

The fstab(5) manual page lists all the available options.

Some applications (e.g. mutt) require file locking to operate correctly. In the case of NFS, rpc.lockd can be used for file locking. To enable it, add the following to the /etc/rc.conf file on both client and server (it is assumed that the NFS client and server are configured already):

Start the application by using:

If real locking between the NFS clients and NFS server is not required, it is possible to let the NFS client do locking locally by passing -L to mount_nfs(8). Refer to the mount_nfs(8) manual page for further details.

NFS has many practical uses. Some of the more common ones are listed below:

amd(8) (the automatic mounter daemon) automatically mounts a remote file system whenever a file or directory within that file system is accessed. Filesystems that are inactive for a period of time will also be automatically unmounted by amd. Using amd provides a simple alternative to permanent mounts, as permanent mounts are usually listed in /etc/fstab.

amd operates by attaching itself as an NFS server to the /host and /net directories. When a file is accessed within one of these directories, amd looks up the corresponding remote mount and automatically mounts it. /net is used to mount an exported file system from an IP address, while /host is used to mount an export from a remote hostname.

An access to a file within /host/foobar/usr would tell amd to attempt to mount the /usr export on the host foobar.

As seen in the example, the showmount shows /usr as an export. When changing directories to /host/foobar/usr, amd attempts to resolve the hostname foobar and automatically mount the desired export.

amd can be started by the startup scripts by placing the following lines in /etc/rc.conf:

Additionally, custom flags can be passed to amd from the amd_flags option. By default, amd_flags is set to:

The /etc/amd.map file defines the default options that exports are mounted with. The /etc/amd.conf file defines some of the more advanced features of amd.

Consult the amd(8) and amd.conf(8) manual pages for more information.

Certain Ethernet adapters for ISA PC systems have limitations which can lead to serious network problems, particularly with NFS. This difficulty is not specific to FreeBSD, but FreeBSD systems are affected by it.

The problem nearly always occurs when (FreeBSD) PC systems are networked with high-performance workstations, such as those made by Silicon Graphics, Inc., and Sun Microsystems, Inc. The NFS mount will work fine, and some operations may succeed, but suddenly the server will seem to become unresponsive to the client, even though requests to and from other systems continue to be processed. This happens to the client system, whether the client is the FreeBSD system or the workstation. On many systems, there is no way to shut down the client gracefully once this problem has manifested itself. The only solution is often to reset the client, because the NFS situation cannot be resolved.

Though the "correct" solution is to get a higher performance and capacity Ethernet adapter for the FreeBSD system, there is a simple workaround that will allow satisfactory operation. If the FreeBSD system is the server, include the option -w=1024 on the mount from the client. If the FreeBSD system is the client, then mount the NFS file system with the option -r=1024. These options may be specified using the fourth field of the fstab entry on the client for automatic mounts, or by using the -o parameter of the mount(8) command for manual mounts.

It should be noted that there is a different problem, sometimes mistaken for this one, when the NFS servers and clients are on different networks. If that is the case, make certain that your routers are routing the necessary UDP information, or you will not get anywhere, no matter what else you are doing.

In the following examples, fastws is the host (interface) name of a high-performance workstation, and freebox is the host (interface) name of a FreeBSD system with a lower-performance Ethernet adapter. Also, /sharedfs will be the exported NFS file system (see exports(5)), and /project will be the mount point on the client for the exported file system. In all cases, note that additional options, such as hard or soft and bg may be desirable in your application.

Examples for the FreeBSD system (freebox) as the client in /etc/fstab on freebox:

As a manual mount command on freebox:

Examples for the FreeBSD system as the server in /etc/fstab on fastws:

As a manual mount command on fastws:

Nearly any 16-bit Ethernet adapter will allow operation without the above restrictions on the read or write size.

For anyone who cares, here is what happens when the failure occurs, which also explains why it is unrecoverable. NFS typically works with a "block" size of 8 K (though it may do fragments of smaller sizes). Since the maximum Ethernet packet is around 1500 bytes, the NFS "block" gets split into multiple Ethernet packets, even though it is still a single unit to the upper-level code, and must be received, assembled, and acknowledged as a unit. The high-performance workstations can pump out the packets which comprise the NFS unit one right after the other, just as close together as the standard allows. On the smaller, lower capacity cards, the later packets overrun the earlier packets of the same unit before they can be transferred to the host and the unit as a whole cannot be reconstructed or acknowledged. As a result, the workstation will time out and try again, but it will try again with the entire 8 K unit, and the process will be repeated, ad infinitum.

By keeping the unit size below the Ethernet packet size limitation, we ensure that any complete Ethernet packet received can be acknowledged individually, avoiding the deadlock situation.

Overruns may still occur when a high-performance workstations is slamming data out to a PC system, but with the better cards, such overruns are not guaranteed on NFS "units". When an overrun occurs, the units affected will be retransmitted, and there will be a fair chance that they will be received, assembled, and acknowledged.

NIS, which stands for Network Information Services, was developed by Sun Microsystems to centralize administration of UNIX® (originally SunOS™) systems. It has now essentially become an industry standard; all major UNIX® like systems (Solaris™, HP-UX, AIX®, Linux, NetBSD, OpenBSD, FreeBSD, etc) support NIS.

NIS was formerly known as Yellow Pages, but because of trademark issues, Sun changed the name. The old term (and yp) is still often seen and used.

It is a RPC-based client/server system that allows a group of machines within an NIS domain to share a common set of configuration files. This permits a system administrator to set up NIS client systems with only minimal configuration data and add, remove or modify configuration data from a single location.

It is similar to the Windows NT® domain system; although the internal implementation of the two are not at all similar, the basic functionality can be compared.

There are several terms and several important user processes that you will come across when attempting to implement NIS on FreeBSD, whether you are trying to create an NIS server or act as an NIS client:

There are three types of hosts in an NIS environment: master servers, slave servers, and clients. Servers act as a central repository for host configuration information. Master servers hold the authoritative copy of this information, while slave servers mirror this information for redundancy. Clients rely on the servers to provide this information to them.

Information in many files can be shared in this manner. The master.passwd, group, and hosts files are commonly shared via NIS. Whenever a process on a client needs information that would normally be found in these files locally, it makes a query to the NIS server that it is bound to instead.

This section will deal with setting up a sample NIS environment.

In general, any remote user can issue an RPC to ypserv(8) and retrieve the contents of your NIS maps, provided the remote user knows your domainname. To prevent such unauthorized transactions, ypserv(8) supports a feature called "securenets" which can be used to restrict access to a given set of hosts. At startup, ypserv(8) will attempt to load the securenets information from a file called /var/yp/securenets.

If ypserv(8) receives a request from an address that matches one of these rules, it will process the request normally. If the address fails to match a rule, the request will be ignored and a warning message will be logged. If the /var/yp/securenets file does not exist, ypserv will allow connections from any host.

The ypserv program also has support for Wietse Venema’s TCP Wrapper package. This allows the administrator to use the TCP Wrapper configuration files for access control instead of /var/yp/securenets.

In our lab, there is a machine basie that is supposed to be a faculty only workstation. We do not want to take this machine out of the NIS domain, yet the passwd file on the master NIS server contains accounts for both faculty and students. What can we do?

There is a way to bar specific users from logging on to a machine, even if they are present in the NIS database. To do this, all you must do is add -username to the end of the /etc/master.passwd file on the client machine, where username is the username of the user you wish to bar from logging in. This should preferably be done using vipw, since vipw will sanity check your changes to /etc/master.passwd, as well as automatically rebuild the password database when you finish editing. For example, if we wanted to bar user bill from logging on to basie we would:

The method shown in the previous section works reasonably well if you need special rules for a very small number of users and/or machines. On larger networks, you will forget to bar some users from logging onto sensitive machines, or you may even have to modify each machine separately, thus losing the main benefit of NIS: centralized administration.

The NIS developers' solution for this problem is called netgroups. Their purpose and semantics can be compared to the normal groups used by UNIX® file systems. The main differences are the lack of a numeric ID and the ability to define a netgroup by including both user accounts and other netgroups.

Netgroups were developed to handle large, complex networks with hundreds of users and machines. On one hand, this is a Good Thing if you are forced to deal with such a situation. On the other hand, this complexity makes it almost impossible to explain netgroups with really simple examples. The example used in the remainder of this section demonstrates this problem.

Let us assume that your successful introduction of NIS in your laboratory caught your superiors' interest. Your next job is to extend your NIS domain to cover some of the other machines on campus. The two tables contain the names of the new users and new machines as well as brief descriptions of them.

If you tried to implement these restrictions by separately blocking each user, you would have to add one -user line to each system’s passwd for each user who is not allowed to login onto that system. If you forget just one entry, you could be in trouble. It may be feasible to do this correctly during the initial setup, however you will eventually forget to add the lines for new users during day-to-day operations. After all, Murphy was an optimist.

Handling this situation with netgroups offers several advantages. Each user need not be handled separately; you assign a user to one or more netgroups and allow or forbid logins for all members of the netgroup. If you add a new machine, you will only have to define login restrictions for netgroups. If a new user is added, you will only have to add the user to one or more netgroups. Those changes are independent of each other: no more "for each combination of user and machine do…​" If your NIS setup is planned carefully, you will only have to modify exactly one central configuration file to grant or deny access to machines.

The first step is the initialization of the NIS map netgroup. FreeBSD’s ypinit(8) does not create this map by default, but its NIS implementation will support it once it has been created. To create an empty map, simply type

and start adding content. For our example, we need at least four netgroups: IT employees, IT apprentices, normal employees and interns.

IT_EMP, IT_APP etc. are the names of the netgroups. Each bracketed group adds one or more user accounts to it. The three fields inside a group are:

Each of these fields can contain wildcards. See netgroup(5) for details.

Activating and distributing your new NIS map is easy:

This will generate the three NIS maps netgroup, netgroup.byhost and netgroup.byuser. Use ypcat(1) to check if your new NIS maps are available:

The output of the first command should resemble the contents of /var/yp/netgroup. The second command will not produce output if you have not specified host-specific netgroups. The third command can be used to get the list of netgroups for a user.

The client setup is quite simple. To configure the server war, you only have to start vipw(8) and replace the line

with

Now, only the data for the users defined in the netgroup IT_EMP is imported into war's password database and only these users are allowed to login.

Unfortunately, this limitation also applies to the ~ function of the shell and all routines converting between user names and numerical user IDs. In other words, cd ~user will not work, ls -l will show the numerical ID instead of the username and find . -user joe -print will fail with No such user. To fix this, you will have to import all user entries without allowing them to login onto your servers.

This can be achieved by adding another line to /etc/master.passwd. This line should contain:

+:::::::::/sbin/nologin, meaning "Import all entries but replace the shell with /sbin/nologin in the imported entries". You can replace any field in the passwd entry by placing a default value in your /etc/master.passwd.

After this change, you will only have to change one NIS map if a new employee joins the IT department. You could use a similar approach for the less important servers by replacing the old +::::::::: in their local version of /etc/master.passwd with something like this:

The corresponding lines for the normal workstations could be:

And everything would be fine until there is a policy change a few weeks later: The IT department starts hiring interns. The IT interns are allowed to use the normal workstations and the less important servers; and the IT apprentices are allowed to login onto the main servers. You add a new netgroup IT_INTERN, add the new IT interns to this netgroup and start to change the configuration on each and every machine…​ As the old saying goes: "Errors in centralized planning lead to global mess".

NIS' ability to create netgroups from other netgroups can be used to prevent situations like these. One possibility is the creation of role-based netgroups. For example, you could create a netgroup called BIGSRV to define the login restrictions for the important servers, another netgroup called SMALLSRV for the less important servers and a third netgroup called USERBOX for the normal workstations. Each of these netgroups contains the netgroups that are allowed to login onto these machines. The new entries for your NIS map netgroup should look like this:

This method of defining login restrictions works reasonably well if you can define groups of machines with identical restrictions. Unfortunately, this is the exception and not the rule. Most of the time, you will need the ability to define login restrictions on a per-machine basis.

Machine-specific netgroup definitions are the other possibility to deal with the policy change outlined above. In this scenario, the /etc/master.passwd of each box contains two lines starting with "+". The first of them adds a netgroup with the accounts allowed to login onto this machine, the second one adds all other accounts with /sbin/nologin as shell. It is a good idea to use the "ALL-CAPS" version of the machine name as the name of the netgroup. In other words, the lines should look like this:

Once you have completed this task for all your machines, you will not have to modify the local versions of /etc/master.passwd ever again. All further changes can be handled by modifying the NIS map. Here is an example of a possible netgroup map for this scenario with some additional goodies:

If you are using some kind of database to manage your user accounts, you should be able to create the first part of the map with your database’s report tools. This way, new users will automatically have access to the boxes.

One last word of caution: It may not always be advisable to use machine-based netgroups. If you are deploying a couple of dozen or even hundreds of identical machines for student labs, you should use role-based netgroups instead of machine-based netgroups to keep the size of the NIS map within reasonable limits.

There are still a couple of things that you will need to do differently now that you are in an NIS environment.

FreeBSD’s ypserv has some support for serving NIS v1 clients. FreeBSD’s NIS implementation only uses the NIS v2 protocol, however other implementations include support for the v1 protocol for backwards compatibility with older systems. The ypbind daemons supplied with these systems will try to establish a binding to an NIS v1 server even though they may never actually need it (and they may persist in broadcasting in search of one even after they receive a response from a v2 server). Note that while support for normal client calls is provided, this version of ypserv does not handle v1 map transfer requests; consequently, it cannot be used as a master or slave in conjunction with older NIS servers that only support the v1 protocol. Fortunately, there probably are not any such servers still in use today.

Care must be taken when running ypserv in a multi-server domain where the server machines are also NIS clients. It is generally a good idea to force the servers to bind to themselves rather than allowing them to broadcast bind requests and possibly become bound to each other. Strange failure modes can result if one server goes down and others are dependent upon it. Eventually all the clients will time out and attempt to bind to other servers, but the delay involved can be considerable and the failure mode is still present since the servers might bind to each other all over again.

You can force a host to bind to a particular server by running ypbind with the -S flag. If you do not want to do this manually each time you reboot your NIS server, you can add the following lines to your /etc/rc.conf:

See ypbind(8) for further information.

One of the most common issues that people run into when trying to implement NIS is password format compatibility. If your NIS server is using DES encrypted passwords, it will only support clients that are also using DES. For example, if you have Solaris™ NIS clients in your network, then you will almost certainly need to use DES encrypted passwords.

To check which format your servers and clients are using, look at /etc/login.conf. If the host is configured to use DES encrypted passwords, then the default class will contain an entry like this:

Other possible values for the passwd_format capability include blf and md5 (for Blowfish and MD5 encrypted passwords, respectively).

If you have made changes to /etc/login.conf, you will also need to rebuild the login capability database, which is achieved by running the following command as root:

Next, in order to ensure that passwords are encrypted with the format that you have chosen, you should also check that the crypt_default in /etc/auth.conf gives precedence to your chosen password format. To do this, place the format that you have chosen first in the list. For example, when using DES encrypted passwords, the entry would be:

Having followed the above steps on each of the FreeBSD based NIS servers and clients, you can be sure that they all agree on which password format is used within your network. If you have trouble authenticating on an NIS client, this is a pretty good place to start looking for possible problems. Remember: if you want to deploy an NIS server for a heterogenous network, you will probably have to use DES on all systems because it is the lowest common standard.

DHCP, the Dynamic Host Configuration Protocol, describes the means by which a system can connect to a network and obtain the necessary information for communication upon that network. FreeBSD versions prior to 6.0 use the ISC (Internet Software Consortium) DHCP client (dhclient(8)) implementation. Later versions use the OpenBSD dhclient taken from OpenBSD 3.7. All information here regarding dhclient is for use with either of the ISC or OpenBSD DHCP clients. The DHCP server is the one included in the ISC distribution.

This section describes both the client-side components of the ISC and OpenBSD DHCP client and server-side components of the ISC DHCP system. The client-side program, dhclient, comes integrated within FreeBSD, and the server-side portion is available from the net/isc-dhcp3-server port. The dhclient(8), dhcp-options(5), and dhclient.conf(5) manual pages, in addition to the references below, are useful resources.

When dhclient, the DHCP client, is executed on the client machine, it begins broadcasting requests for configuration information. By default, these requests are on UDP port 68. The server replies on UDP 67, giving the client an IP address and other relevant network information such as netmask, router, and DNS servers. All of this information comes in the form of a DHCP "lease" and is only valid for a certain time (configured by the DHCP server maintainer). In this manner, stale IP addresses for clients no longer connected to the network can be automatically reclaimed.

DHCP clients can obtain a great deal of information from the server. An exhaustive list may be found in dhcp-options(5).

FreeBSD fully integrates the ISC or OpenBSD DHCP client, dhclient (according to the FreeBSD version you run). DHCP client support is provided within both the installer and the base system, obviating the need for detailed knowledge of network configurations on any network that runs a DHCP server. dhclient has been included in all FreeBSD distributions since 3.2.

DHCP is supported by sysinstall. When configuring a network interface within sysinstall, the second question asked is: "Do you want to try DHCP configuration of the interface?". Answering affirmatively will execute dhclient, and if successful, will fill in the network configuration information automatically.

There are two things you must do to have your system use DHCP upon startup:

The DHCP server, dhcpd, is included as part of the net/isc-dhcp3-server port in the ports collection. This port contains the ISC DHCP server and documentation.

The DHCP protocol is fully described in RFC 2131. An informational resource has also been set up at http://www.dhcp.org/.

FreeBSD utilizes, by default, a version of BIND (Berkeley Internet Name Domain), which is the most common implementation of the DNS protocol. DNS is the protocol through which names are mapped to IP addresses, and vice versa. For example, a query for www.FreeBSD.org will receive a reply with the IP address of The FreeBSD Project’s web server, whereas, a query for ftp.FreeBSD.org will return the IP address of the corresponding FTP machine. Likewise, the opposite can happen. A query for an IP address can resolve its hostname. It is not necessary to run a name server to perform DNS lookups on a system.

FreeBSD currently comes with BIND9 DNS server software by default. Our installation provides enhanced security features, a new file system layout and automated chroot(8) configuration.

DNS is coordinated across the Internet through a somewhat complex system of authoritative root, Top Level Domain (TLD), and other smaller-scale name servers which host and cache individual domain information.

Currently, BIND is maintained by the Internet Software Consortium http://www.isc.org/.

To understand this document, some terms related to DNS must be understood.

Examples of zones:

As one can see, the more specific part of a hostname appears to its left. For example, example.org. is more specific than org., as org. is more specific than the root zone. The layout of each part of a hostname is much like a file system: the /dev directory falls within the root, and so on.

Name servers usually come in two forms: an authoritative name server, and a caching name server.

An authoritative name server is needed when:

A caching name server is needed when:

When one queries for www.FreeBSD.org, the resolver usually queries the uplink ISP’s name server, and retrieves the reply. With a local, caching DNS server, the query only has to be made once to the outside world by the caching DNS server. Every additional query will not have to look to the outside of the local network, since the information is cached locally.

In FreeBSD, the BIND daemon is called named for obvious reasons.

Depending on how a given zone is configured on the server, the files related to that zone can be found in the master, slave, or dynamic subdirectories of the /etc/namedb directory. These files contain the DNS information that will be given out by the name server in response to queries.

Since BIND is installed by default, configuring it all is relatively simple.

The default named configuration is that of a basic resolving name server, ran in a chroot(8) environment. To start the server one time with this configuration, use the following command:

To ensure the named daemon is started at boot each time, put the following line into the /etc/rc.conf:

There are obviously many configuration options for /etc/namedb/named.conf that are beyond the scope of this document. However, if you are interested in the startup options for named on FreeBSD, take a look at the named_* flags in /etc/defaults/rc.conf and consult the rc.conf(5) manual page. The Χρησιμοποιώντας Το Σύστημα rc Στο FreeBSD section is also a good read.

Configuration files for named currently reside in /etc/namedb directory and will need modification before use, unless all that is needed is a simple resolver. This is where most of the configuration will be performed.

A caching name server is a name server that is not authoritative for any zones. It simply asks queries of its own, and remembers them for later use. To set one up, just configure the name server as usual, omitting any inclusions of zones.

Although BIND is the most common implementation of DNS, there is always the issue of security. Possible and exploitable security holes are sometimes found.

While FreeBSD automatically drops named into a chroot(8) environment; there are several other security mechanisms in place which could help to lure off possible DNS service attacks.

It is always good idea to read CERT's security advisories and to subscribe to the ηλεκτρονική λίστα Ανακοινώσεων για Θέματα Ασφάλειας του FreeBSD to stay up to date with the current Internet and FreeBSD security issues.

BIND/named manual pages: rndc(8) named(8) named.conf(8)

Το FreeBSD χρησιμοποιείται για να φιλοξενεί παγκοσμίως ιστοσελίδες μεγάλης επισκεψιμότητας. Οι περισσότεροι διακομιστές web στο διαδίκτυο χρησιμοποιούν τον εξυπηρετητή HTTP Apache. Τα πακέτα λογισμικού του Apache θα πρέπει να περιέχονται στο μέσο εγκατατάστασης του FreeBSD που χρησιμοποιείτε. Αν δεν εγκαταστήσατε τον Apache κατά την διάρκεια της εγκατάστασης του FreeBSD, τότε μπορείτε να τον εγκαταστήσετε από το πακέτο www/apache13 ή από το πακέτο www/apache20.

Αφού ολοκληρώσετε επιτυχώς την εγκατάσταση του Apache, θα πρέπει να κάνετε τις απαραίτητες ρυθμίσεις.

Στο FreeBSD το σημαντικότερο αρχείο ρυθμίσεων του Εξυπηρετητή HTTP Apache είναι το /usr/local/etc/apache/httpd.conf. Είναι ένα τυπικό UNIX® ρυθμιστικό αρχείο κειμένου, με γραμμές σχολίων που ξεκινούν με τον χαρακτήρα #. Σκοπός μας εδώ δεν είναι μια ολοκληρωμένη περιγραφή όλων των πιθανών επιλογών, επομένως θα περιγράψουμε μόνο τις πιο δημοφιλείς επιλογές ρυθμίσεις (configuration directives).

Πριν κάνετε οποιαδήποτε αλλαγή, είναι καλό να δημιουργείτε αντίγραφα ασφαλείας (backup) του αρχείου ρυθμίσεων του Apache. Μόλις κρίνετε πως είστε ικανοποιημένος με τις αρχικές ρυθμίσεις μπορείτε να ξεκινήσετε με την εκτέλεση του Apache.

O Apache δεν τρέχει διαμέσου του υπερ-διακομιστή inetd όπως κάνουν πολλοί άλλοι δικτυακοί εξυπηρετητές. Είναι ρυθμισμένος να τρέχει αυτόνομα για να εξυπηρετεί καλύτερα τις αιτήσεις HTTP των πελατών του, δηλαδή των προγραμμάτων πλοήγησης (browsers). Η εγκατάσταση του Apache από τα FreeBSD Ports περιέχει ένα βοηθητικό shell script για την εκκίνηση, το σταμάτημα και την επανεκκίνηση του εξυπηρετητή. Για να ξεκινήσετε τον Apache για πρώτη φορά, απλά τρέξτε:

Μπορείτε οποιαδήποτε στιγμή να σταματήσετε τον εξυπηρετητή, πληκτρολογώντας:

Μετά από αλλαγές που πιθανώς να κάνατε για οποιονδήποτε λόγο στο αρχείο ρυθμίσεων, θα χρειαστεί να επανεκκινήσετε τον εξυπηρετητή:

Για να επανεκκινήσετε τον Apache δίχως να διακόψετε τις τρέχουσες συνδέσεις, τρέξτε:

Περισσότερες πληροφορίες θα βρείτε στη σελίδα βοήθειας του apachectl(8).

Για να ξεκινάει ο Apache αυτόματα κατά τη διάρκεια εκκίνησης του συστήματος, προσθέστε την ακόλουθη γραμμή στο /etc/rc.conf:

Αν επιθυμείτε να παρέχονται κατά την εκκίνηση του συστήματος πρόσθετες επιλογές στην γραμμή εντολών για το πρόγραμμα Apache httpd μπορείτε να τις δηλώσετε με μια πρόσθετη γραμμή στο rc.conf:

Τώρα που έχει ξεκινήσει ο εξυπηρετής web, μπορείτε να δείτε την ιστοσελίδα σας στοχεύοντας το πρόγραμμα πλοήγησης στο http://localhost/. Η προκαθορισμένη σελίδα που εμφανίζεται είναι η /usr/local/www/data/index.html.

Ο Apache υποστηρίζει δύο διαφορετικούς τύπους Virtual Hosting. Το Ονομαστικό virtual hosting χρησιμοποιεί τους HTTP/1.1 headers για να καθορίσει τον κόμβο. Αυτό επιτρέπει την κοινή χρήση της ίδιας IP για πολλά και διαφορετικά domains.

Για να ρυθμίσετε τον Apache να χρησιμοποιεί το Ονομαστικό Virtual Hosting εισάγετε μια καταχώριση στο httpd.conf σαν την ακόλουθη:

Αν ο διακομιστής web ονομάζεται www.domain.tld και επιθυμείτε να εγκαταστήσετε ένα virtual domain για το www.someotherdomain.tld τότε θα πρέπει να προσθέσετε τις ακόλουθες καταχωρήσεις στο httpd.conf:

Αντικαταστήστε τις παραπάνω διευθύνσεις με εκείνες που επιθυμείτε να χρησιμοποιήσετε και την κατάλληλη διαδρομή προς τα έγγραφά σας.

Για περισσότερες πληροφορίες σχετικά με τις ρυθμίσεις για τα virtual host, σας προτρέπουμε να συμβουλευτείτε την επίσημη τεκμηρίωση του Apache στο http://httpd.apache.org/docs/vhosts/.

Υπάρχουν πολλοί και διάφοροι διαθέσιμοι τύποι αρθρωμάτων (modules) για τον Apache, τα οποία επεκτείνουν κι εμπλουτίζουν τις λειτουργίες του βασικού εξυπηρετητή. Η Συλλογή των Ports του FreeBSD παρέχει έναν εύκολο τρόπο για να εγκαταστήσετε τον Apache και μερικά από τα πιο δημοφιλή αρθρώματα.

Το Πρωτόκολο Μεταφοράς Αρχείων (File Transfer Protocol - FTP) παρέχει στους χρήστες έναν εύκολο τρόπο για να μεταφέρουν τα αρχεία τους από και προς έναν εξυπηρετητή FTP. Το βασικό σύστημα του FreeBSD περιλαμβάνει ένα εξυπηρετητή FTP, το ftpd. Αυτό καθιστά την εγκατάσταση και την διαχείριση του εξυπηρετητή FTP πολύ εύκολη υπόθεση.

Το πιο σημαντικό βήμα στις ρυθμίσεις είναι να αποφασίσετε σε ποιούς λογαριασμούς θα επιτραπεί η πρόσβαση στον εξυπηρετητή FTP. Ένα συνηθισμένο σύστημα FreeBSD δημιουργεί μερικούς λογαριασμούς συστήματος για διάφορους δαίμονες, αλλά δεν πρέπει να επιτρέπεται η πρόσβαση στο σύστημα με αυτούς τους λογαριασμούς. Το αρχείο /etc/ftpusers περιέχει μια λίστα από χρήστες για τους οποίους απορρίπτεται η πρόσβαση μέσω FTP. Προεπιλεγμένα, περιέχονται οι προαναφερθέντες λογαριασμοί του συστήματος, αλλά μπορείτε επίσης να προσθέσετε συγκεκριμένους χρήστες που δε θα πρέπει να έχουν πρόσβαση μέσω FTP.

Μπορείτε αν θέλετε να περιορίσετε την πρόσβαση σε κάποιους χρήστες, δίχως όμως να τους εμποδίσετε πλήρως. Αυτό μπορεί να συμβεί με τις ρυθμίσεις του αρχείου /etc/ftpchroot. Αυτό το αρχείο περιέχει λίστες χρηστών και ομάδων περιορισμένης πρόσβασης FTP. Η σελίδα βοήθειας ftpchroot(5) περιέχει όλες τις απαραίτητες λεπτομέρειες, επομένως δε θα χρειαστεί να μπούμε σε λεπτομέρειες εδώ.

Αν επιθυμείτε να ενεργοποιήσετε ανώνυμη πρόσβαση FTP στον εξυπηρετητή σας, θα πρέπει να δημιουργήσετε, στο FreeBSD σύστημα σας, ένα χρήστη με όνομα ftp . Οι ανώνυμοι χρήστες θα μπορούν να εισέρχονται στον εξυπηρετητή FTP με το γενικό όνομα χρήστη ftp ή με anonymous και με οποιαδήποτε κωδικό πρόσβασης (συνηθίζεται να ζητείται η διεύθυνση email του χρήστη ως κωδικός πρόσβασης). Ο εξυπηρετητής FTP θα καλέσει το chroot(2) μόλις εισέλθη ο ανώνυμος χρήστης, για να του περιορίσει την πρόσβαση, επιτρέποντας του μόνο τον αρχικό κατάλογο (home directory) του χρήστη ftp.

Υπάρχουν δύο αρχεία κειμένου για τον ορισμό μηνυμάτων καλωσορίσματος που θα εμφανίζονται στους πελάτες FTP. Το περιεχόμενο του αρχείου /etc/ftpwelcome εμφανίζεται στους χρήστες πριν φτάσουν στην προτροπή εισόδου. Μετά από μια πετυχημένη είσοδο στο σύστημα, εμφανίζεται το περιεχόμενο του αρχείου /etc/ftpmotd. Παρατηρήστε πως η διαδρομή σε αυτό το αρχείο είναι σχετική με το περιβάλλον πρόσβασης, επομένως για τους ανώνυμους χρήστες θα εμφανίζεται το περιεχόμενο του αρχείου ~ftp/etc/ftpmotd.

Αφού ρυθμίσετε κατάλληλα τον εξυπηρετητή FTP, θα πρέπει να τον ενεργοποιήσετε στο αρχείο /etc/inetd.conf. Το μόνο που χρειάζεται να κάνετε είναι να αφαιρέσετε το σύμβολο σχολιασμού "#" μπροστά από την υπάρχουσα γραμμή ftpd :

Όπως εξηγήσαμε στο Reloading the inetd configuration file, η διεργασία inetd θα πρέπει να ξαναφορτώνεται αν έχουν γίνει αλλαγές στο αρχείο ρυθμίσεων της.

Τώρα μπορείτε να δώσετε τα στοιχεία του λογαριασμού σας για να εισέλθετε στον εξυπηρετητή FTP.

Ο δαίμονας ftpd χρησιμοποιεί το syslog(3) για την δημιουργία μηνυμάτων αναφοράς. Προεπιλεγμένα, ο δαίμονας των log του συστήματος θα εναποθέτει τις σχετικές με το FTP αναφορές στο αρχείο /var/log/xferlog. Η τοποθεσία του αρχείου αναφοράς μπορεί να τροποποιηθεί αλλάζοντας την ακόλουθη γραμμή στο /etc/syslog.conf:

Πρέπει να είστε ενήμεροι για τα προβλήματα που μπορούν να παρουσιαστούν σχετικά με τη λειτουργία ενός ανώνυμου εξυπηρετητή FTP. Ειδικότερα, θα πρέπει να σκεφτείτε σοβαρά αν όντως επιθυμείτε να έχουν δυνατότητα να ανεβάζουν αρχεία οι ανώνυμοι χρήστες σας. Αν αφήσετε οποιονδήποτε ανώνυμο χρήστη να ανεβάζει αρχεία, μπορεί ξαφνικά να ανακαλύψετε πως ο εξυπηρετητής σας FTP χρησιμοποιείται για διακίνηση πειρατικού εμπορικού λογισμικού ή για άλλο, ακόμα χειρότερο, παράνομο υλικό. Εάν όντως χρειάζεται οι χρήστες να έχουν άδεια προσθήκης αρχείων, τότε θα πρέπει να ρυθμίσετε τις άδειες έτσι ώστε τα αρχεία αυτά να μην είναι ορατά από άλλους ανώνυμους χρήστες, έως ότου να πάρουν την ασφαλή έγκριση σας.

Samba is a popular open source software package that provides file and print services for Microsoft® Windows® clients. Such clients can connect to and use FreeBSD filespace as if it was a local disk drive, or FreeBSD printers as if they were local printers.

Samba software packages should be included on your FreeBSD installation media. If you did not install Samba when you first installed FreeBSD, then you can install it from the net/samba3 port or package.

A default Samba configuration file is installed as /usr/local/etc/smb.conf.default. This file must be copied to /usr/local/etc/smb.conf and customized before Samba can be used.

The smb.conf file contains runtime configuration information for Samba, such as definitions of the printers and "file system shares" that you would like to share with Windows® clients. The Samba package includes a web based tool called swat which provides a simple way of configuring the smb.conf file.

The net/samba3 port adds a new startup script, which can be used to control Samba. To enable this script, so that it can be used for example to start, stop or restart Samba, add the following line to the /etc/rc.conf file:

It is possible then to start Samba at any time by typing:

Please refer to Χρησιμοποιώντας Το Σύστημα rc Στο FreeBSD for more information about using rc scripts.

Samba actually consists of three separate daemons. You should see that both the nmbd and smbd daemons are started by the samba.sh script. If you enabled winbind name resolution services in smb.conf, then you will also see that the winbindd daemon is started.

You can stop Samba at any time by typing :

Samba is a complex software suite with functionality that allows broad integration with Microsoft® Windows® networks. For more information about functionality beyond the basic installation described here, please see http://www.samba.org.

Με το πέρασμα του χρόνου, το ρολόι συστήματος ενός υπολογιστή έχει την τάση να αποσυγχρονίζεται. Το Πρωτόκολο Χρονισμού Δικτύων (Network Time Protocol ή NTP) παρέχει ένα τρόπο για να εξασφαλίσετε την ακρίβεια του clock σας.

Πολλές διαδικτυακές υπηρεσίες βασίζονται ή ωφελούνται σε μεγάλο βαθμό από την ακρίβεια του ρολογιού συστήματος ενός υπολογιστή. Για παράδειγμα, ένας εξυπηρετητής web μπορεί να δεχθεί αιτήσεις για αποστολή ενός αρχείου όταν το αρχείο αυτό έχει τροποποιηθεί μέχρι κάποια συγκεκριμένη ώρα. Σε ένα περιβάλλον τοπικού δικτύου, είναι θεμελιώδης αρχή οι υπολογιστές που θα διαμοιραστούν αρχεία από τον ίδιο διακομιστή αρχείων να έχουν συγχρονισμένα ρολόγια, έτσι ώστε τα χρονικά χαρακτηριστικά του αρχείου να συμφωνούν. Επίσης διεργασίες όπως η cron(8) βασίζονται σε ένα ακριβές ρολόι ώστε να μπορούν να τρέχουν εντολές στους προκαθορισμένους χρόνους.

Το FreeBSD διατίθεται με τον εξυπηρετητή NTP ntpd(8), ο οποίος μπορεί να χρησιμοποιηθεί για να συγχρονίζει το ρολόι συστήματος του υπολογιστή σας, εξετάζοντας άλλους εξυπηρετητές NTP ή να παρέχει ο ίδιος υπηρεσίες συγχρονισμού σε άλλα μηχανήματα.

Για να συγχρονίσετε το ρολόι συστήματος του υπολογιστή σας θα πρέπει να βρείτε έναν ή περισσότερους διαθέσιμους NTP εξυπηρετητές για να χρησιμοποιήσετε. Ο διαχειριστής δικτύου ή ο ISP σας μπορεί να έχουν εγκαταστήσει κάποιον εξυπηρετητή NTP για αυτό το σκοπό - ελέγξτε την τεκμηρίωση τους να δείτε αν υπάρχει τέτοια περίπτωση. Επιπλέον, υπάρχει μία online λίστα εξυπηρετητών δημόσιας πρόσβασης, που μπορείτε να χρησιμοποιήσετε για να βρείτε έναν κοντινό εξυπηρετητή NTP. Όποιον εξυπηρετητή κι αν επιλέξετε, ενημερωθείτε για την πολιτική χρήσης του και ζητήστε άδεια να τον χρησιμοποιήσετε αν χρειάζεται τέτοια άδεια.

Είναι καλή ιδέα να επιλέξετε πολλούς εξυπηρετητές NTP, οι οποίοι να μην συνδέονται μεταξύ τους, στην περίπτωση που κάποιος από τους εξυπηρετητές που χρησιμοποιείτε γίνει απρόσιτος ή το ρολόι του είναι ανακριβές. Ο εξυπηρετητής ntpd(8) του FreeBSD χειρίζεται έξυπνα τις απαντήσεις που λαμβάνει από τους υπόλοιπους εξυπηρετητές - ευνοεί τους πιο αξιόπιστους και δείχνει μικρότερη προτίμηση στους λιγότερο αξιόπιστους εξυπηρετητές.

Για να βεβαιωθείτε πως ο εξυπηρετητής NTP θα ξεκινάει κατά την διάρκεια εκκίνησης του συστήματος, προσθέστε τη γραμμή ntpd_enable="YES" στο /etc/rc.conf. Για να ξεκινήσετε τον εξυπηρετητή δίχως να επανεκκινήσετε το μηχάνημα σας, τρέξτε ntpd(8) προσδιορίζοντας κάθε επιπρόσθετη παράμετρο από τα ntpd_flags στο /etc/rc.conf. Για παράδειγμα:

Το πρόγραμμα ntpd(8) δεν χρειάζεται μια μόνιμη σύνδεση στο Ίντερνετ για να δουλέψει σωστά. Αν έχετε μια προσωρινή σύνδεση που είναι ρυθμισμένη να κάνει κλήσεις μέσω τηλεφώνου (dial out on demand), είναι καλό να μην είναι η κίνηση δεδομένων του NTP το αίτιο της κλήσης ή αυτή που θα κρατάει ενεργή την σύνδεση. Αν χρησιμοποιείτε PPP χρήστη, μπορείτε να χρησιμοποιήσετε φίλτρα στους κώδικες παραπομπής του /etc/ppp/ppp.conf, όπως για παράδειγμα:

Για περισσότερες λεπτομέρειες δείτε το PACKET FILTERING στην ενότητα ppp(8) και τα παραδείγματα στο /usr/shared/examples/ppp/.

Η τεκμηρίωση για τους εξυπηρετητές NTP διατίθεται και σε φόρμα HTML στο /usr/shared/doc/ntp/.