章 29. 網路伺服器

Configuration of inetd is done by editing /etc/inetd.conf. Each line of this configuration file represents an application which can be started by inetd. By default, every line starts with a comment (), meaning that inetd is not listening for any applications. To configure inetd to listen for an application’s connections, remove the at the beginning of the line for that application.

After saving your edits, configure inetd to start at system boot by editing /etc/rc.conf:

To start inetd now, so that it listens for the service you configured, type:

Once inetd is started, it needs to be notified whenever a modification is made to /etc/inetd.conf:

Typically, the default entry for an application does not need to be edited beyond removing the #. In some situations, it may be appropriate to edit the default entry.

As an example, this is the default entry for ftpd(8) over IPv4:

The seven columns in an entry are as follows:

where:

Like most server daemons, inetd has a number of options that can be used to modify its behavior. By default, inetd is started with -wW -C 60. These options enable TCP wrappers for all services, including internal services, and prevent any IP address from requesting any service more than 60 times per minute.

To change the default options which are passed to inetd, add an entry for inetd_flags in /etc/rc.conf. If inetd is already running, restart it with service inetd restart.

The available rate limiting options are:

Additional options are available. Refer to inetd(8) for the full list of options.

Many of the daemons which can be managed by inetd are not security-conscious. Some daemons, such as fingerd, can provide information that may be useful to an attacker. Only enable the services which are needed and monitor the system for excessive connection attempts. max-connections-per-ip-per-minute, max-child and max-child-per-ip can be used to limit such attacks.

By default, TCP wrappers is enabled. Consult hosts_access(5) for more information on placing TCP restrictions on various inetd invoked daemons.

The file systems which the NFS server will share are specified in /etc/exports. Each line in this file specifies a file system to be exported, which clients have access to that file system, and any access options. When adding entries to this file, each exported file system, its properties, and allowed hosts must occur on a single line. If no clients are listed in the entry, then any client on the network can mount that file system.

The following /etc/exports entries demonstrate how to export file systems. The examples can be modified to match the file systems and client names on the reader’s network. There are many options that can be used in this file, but only a few will be mentioned here. See exports(5) for the full list of options.

This example shows how to export /cdrom to three hosts named alpha, bravo, and charlie:

The -ro flag makes the file system read-only, preventing clients from making any changes to the exported file system. This example assumes that the host names are either in DNS or in /etc/hosts. Refer to hosts(5) if the network does not have a DNS server.

The next example exports /home to three clients by IP address. This can be useful for networks without DNS or /etc/hosts entries. The -alldirs flag allows subdirectories to be mount points. In other words, it will not automatically mount the subdirectories, but will permit the client to mount the directories that are required as needed.

This next example exports /a so that two clients from different domains may access that file system. The -maproot=root allows root on the remote system to write data on the exported file system as root. If -maproot=root is not specified, the client’s root user will be mapped to the server’s nobody account and will be subject to the access limitations defined for nobody.

A client can only be specified once per file system. For example, if /usr is a single file system, these entries would be invalid as both entries specify the same host:

The correct format for this situation is to use one entry:

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

To enable the processes required by the NFS server at boot time, add these options to /etc/rc.conf:

The server can be started now by running this command:

Whenever the NFS server is started, mountd also starts automatically. However, mountd only reads /etc/exports when it is started. To make subsequent /etc/exports edits take effect immediately, force mountd to reread it:

To enable NFS clients, set this option in each client’s /etc/rc.conf:

Then, run this command on each NFS client:

The client now has everything it needs to mount a remote file system. In these examples, the server’s name is server and the client’s name is client. To mount /home on server to the /mnt mount point on client:

The files and directories in /home will now be available on client, in the /mnt directory.

To mount a remote file system each time the client boots, add it to /etc/fstab:

Refer to fstab(5) for a description of all available options.

Some applications require file locking to operate correctly. To enable locking, add these lines to /etc/rc.conf on both the client and server:

Then start the applications:

If locking is not required on the server, the NFS client can be configured to lock locally by including -L when running mount. Refer to mount_nfs(8) for further details.

The automatic mounter daemon, amd, automatically mounts a remote file system whenever a file or directory within that file system is accessed. File systems that are inactive for a period of time will be automatically unmounted by amd.

This daemon provides an alternative to modifying /etc/fstab to list every client. It 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. For instance, an attempt to access a file within /host/foobar/usr would tell amd to mount the /usr export on the host foobar.

The output from showmount shows /usr as an export. When changing directories to /host/foobar/usr, amd intercepts the request and attempts to resolve the hostname foobar. If successful, amd automatically mounts the desired export.

To enable amd at boot time, add this line to /etc/rc.conf:

To start amd now:

Custom flags can be passed to amd from the amd_flags environment variable. By default, amd_flags is set to:

The default options with which exports are mounted are defined in /etc/amd.map. Some of the more advanced features of amd are defined in /etc/amd.conf.

Consult amd(8) and amd.conf(5) for more information.

The autofs(5) facility is a common name for several components that, together, allow for automatic mounting of remote and local filesystems whenever a file or directory within that file system is accessed. It consists of the kernel component, autofs(5), and several userspace applications: automount(8), automountd(8) and autounmountd(8). It serves as an alternative for amd(8) from previous FreeBSD releases. Amd is still provided for backward compatibility purposes, as the two use different map format; the one used by autofs is the same as with other SVR4 automounters, such as the ones in Solaris, MacOS X, and Linux.

The autofs(5) virtual filesystem is mounted on specified mountpoints by automount(8), usually invoked during boot.

Whenever a process attempts to access file within the autofs(5) mountpoint, the kernel will notify automountd(8) daemon and pause the triggering process. The automountd(8) daemon will handle kernel requests by finding the proper map and mounting the filesystem according to it, then signal the kernel to release blocked process. The autounmountd(8) daemon automatically unmounts automounted filesystems after some time, unless they are still being used.

The primary autofs configuration file is /etc/auto_master. It assigns individual maps to top-level mounts. For an explanation of auto_master and the map syntax, refer to auto_master(5).

There is a special automounter map mounted on /net. When a file is accessed within this directory, autofs(5) looks up the corresponding remote mount and automatically mounts it. For instance, an attempt to access a file within /net/foobar/usr would tell automountd(8) to mount the /usr export from the host foobar.

The output from showmount shows /usr as an export. When changing directories to /host/foobar/usr, automountd(8) intercepts the request and attempts to resolve the hostname foobar. If successful, automountd(8) automatically mounts the source export.

To enable autofs(5) at boot time, add this line to /etc/rc.conf:

Then autofs(5) can be started by running:

The autofs(5) map format is the same as in other operating systems. Information about this format from other sources can be useful, like the Mac OS X document.

Consult the automount(8), automountd(8), autounmountd(8), and auto_master(5) manual pages for more information.

Table 28.1 summarizes the terms and important processes used by NIS:

There are three types of hosts in an NIS environment:

Information in many files can be shared using NIS. 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 describes a sample NIS environment which consists of 15 FreeBSD machines with no centralized point of administration. Each machine has its own /etc/passwd and /etc/master.passwd. These files are kept in sync with each other only through manual intervention. Currently, when a user is added to the lab, the process must be repeated on all 15 machines.

The configuration of the lab will be as follows:

If this is the first time an NIS scheme is being developed, it should be thoroughly planned ahead of time. Regardless of network size, several decisions need to be made as part of the planning process.

The canonical copies of all NIS files are stored on the master server. The databases used to store the information are called NIS maps. In FreeBSD, these maps are stored in /var/yp/[domainname] where [domainname] is the name of the NIS domain. Since multiple domains are supported, it is possible to have several directories, one for each domain. Each domain will have its own independent set of maps.

NIS master and slave servers handle all NIS requests through ypserv(8). This daemon is responsible for receiving incoming requests from NIS clients, translating the requested domain and map name to a path to the corresponding database file, and transmitting data from the database back to the client.

Setting up a master NIS server can be relatively straight forward, depending on environmental needs. Since FreeBSD provides built-in NIS support, it only needs to be enabled by adding the following lines to /etc/rc.conf:

Care must be taken 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.

A server that is also a client can be forced to bind to a particular server by adding these additional lines to /etc/rc.conf:

After saving the edits, type /etc/netstart to restart the network and apply the values defined in /etc/rc.conf. Before initializing the NIS maps, start ypserv(8):

To set up an NIS slave server, log on to the slave server and edit /etc/rc.conf as for the master server. Do not generate any NIS maps, as these already exist on the master server. When running ypinit on the slave server, use -s (for slave) instead of -m (for master). This option requires the name of the NIS master in addition to the domain name, as seen in this example:

This will generate a directory on the slave server called /var/yp/test-domain which contains copies of the NIS master server’s maps. Adding these /etc/crontab entries on each slave server will force the slaves to sync their maps with the maps on the master server:

These entries are not mandatory because the master server automatically attempts to push any map changes to its slaves. However, since clients may depend upon the slave server to provide correct password information, it is recommended to force frequent password map updates. This is especially important on busy networks where map updates might not always complete.

To finish the configuration, run /etc/netstart on the slave server in order to start the NIS services.

An NIS client binds to an NIS server using ypbind(8). This daemon broadcasts RPC requests on the local network. These requests specify the domain name configured on the client. If an NIS server in the same domain receives one of the broadcasts, it will respond to ypbind, which will record the server’s address. If there are several servers available, the client will use the address of the first server to respond and will direct all of its NIS requests to that server. The client will automatically ping the server on a regular basis to make sure it is still available. If it fails to receive a reply within a reasonable amount of time, ypbind will mark the domain as unbound and begin broadcasting again in the hopes of locating another server.

To configure a FreeBSD machine to be an NIS client:

To start the NIS client immediately, execute the following commands as the superuser:

After completing these steps, running ypcat passwd on the client should show the server’s passwd map.

Since RPC is a broadcast-based service, any system running ypbind within the same domain can retrieve the contents of the NIS maps. To prevent unauthorized transactions, ypserv(8) supports a feature called "securenets" which can be used to restrict access to a given set of hosts. By default, this information is stored in /var/yp/securenets, unless ypserv(8) is started with -p and an alternate path. This file contains entries that consist of a network specification and a network mask separated by white space. Lines starting with # are considered to be comments. A sample securenets might look like this:

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 securenets does not exist, ypserv will allow connections from any host.

TCP Wrapper is an alternate mechanism for providing access control instead of securenets. While either access control mechanism adds some security, they are both vulnerable to "IP spoofing" attacks. All NIS-related traffic should be blocked at the firewall.

Servers using securenets may fail to serve legitimate NIS clients with archaic TCP/IP implementations. Some of these implementations set all host bits to zero when doing broadcasts or fail to observe the subnet mask when calculating the broadcast address. While some of these problems can be fixed by changing the client configuration, other problems may force the retirement of these client systems or the abandonment of securenets.

The use of TCP Wrapper increases the latency of the NIS server. The additional delay may be long enough to cause timeouts in client programs, especially in busy networks with slow NIS servers. If one or more clients suffer from latency, convert those clients into NIS slave servers and force them to bind to themselves.

Barring specified users from logging on to individual systems becomes unscaleable on larger networks and quickly loses the main benefit of NIS: centralized administration.

Netgroups were developed to handle large, complex networks with hundreds of users and machines. Their use is comparable to UNIX™ groups, where the main difference is the lack of a numeric ID and the ability to define a netgroup by including both user accounts and other netgroups.

To expand on the example used in this chapter, the NIS domain will be extended to add the users and systems shown in Tables 28.2 and 28.3:

When using netgroups to configure this scenario, each user is assigned to one or more netgroups and logins are then allowed or forbidden for all members of the netgroup. When adding a new machine, login restrictions must be defined for all netgroups. When a new user is added, the account must be added to one or more netgroups. If the NIS setup is planned carefully, only one central configuration file needs modification to grant or deny access to machines.

The first step is the initialization of the NIS netgroup map. In FreeBSD, this map is not created by default. On the NIS master server, use an editor to create a map named /var/yp/netgroup.

This example creates four netgroups to represent IT employees, IT apprentices, employees, and interns:

Each entry configures a netgroup. The first column in an entry is the name of the netgroup. Each set of brackets represents either a group of one or more users or the name of another netgroup. When specifying a user, the three comma-delimited fields inside each group represent:

If a group contains multiple users, separate each user with whitespace. Additionally, each field may contain wildcards. See netgroup(5) for details.

Netgroup names longer than 8 characters should not be used. The names are case sensitive and using capital letters for netgroup names is an easy way to distinguish between user, machine and netgroup names.

Some non-FreeBSD NIS clients cannot handle netgroups containing more than 15 entries. This limit may be circumvented by creating several sub-netgroups with 15 users or fewer and a real netgroup consisting of the sub-netgroups, as seen in this example:

Repeat this process if more than 225 (15 times 15) users exist within a single netgroup.

To activate and distribute the new NIS map:

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

The output of the first command should resemble the contents of /var/yp/netgroup. The second command only produces output if host-specific netgroups were created. The third command is used to get the list of netgroups for a user.

To configure a client, use vipw(8) to specify the name of the netgroup. For example, on the server named war, replace this line:

with

This specifies that only the users defined in the netgroup IT_EMP will be imported into this system’s password database and only those users are allowed to login to this system.

This configuration also applies to the ~ function of the shell and all routines which convert 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 the message No such user. To fix this, import all user entries without allowing them to login into the servers. This can be achieved by adding an extra line:

This line configures the client to import all entries but to replace the shell in those entries with /usr/sbin/nologin.

Make sure that extra line is placed after +@IT_EMP:::::::::. Otherwise, all user accounts imported from NIS will have /usr/sbin/nologin as their login shell and no one will be able to login to the system.

To configure the less important servers, replace the old +::::::::: on the servers with these lines:

The corresponding lines for the workstations would be:

NIS supports the creation of netgroups from other netgroups which can be useful if the policy regarding user access changes. One possibility is the creation of role-based netgroups. For example, one might 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 workstations. Each of these netgroups contains the netgroups that are allowed to login onto these machines. The new entries for the NIS netgroup map would look like this:

This method of defining login restrictions works reasonably well when it is possible to define groups of machines with identical restrictions. Unfortunately, this is the exception and not the rule. Most of the time, the ability to define login restrictions on a per-machine basis is required.

Machine-specific netgroup definitions are another possibility to deal with the policy changes. In this scenario, the /etc/master.passwd of each system contains two lines starting with "+". The first line adds a netgroup with the accounts allowed to login onto this machine and the second line adds all other accounts with /usr/sbin/nologin as shell. It is recommended to use the "ALL-CAPS" version of the hostname as the name of the netgroup:

Once this task is completed on all the machines, there is no longer a need 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:

It may not always be advisable to use machine-based netgroups. When deploying a couple of dozen or hundreds of systems, role-based netgroups instead of machine-based netgroups may be used to keep the size of the NIS map within reasonable limits.

NIS requires that all hosts within an NIS domain use the same format for encrypting passwords. If users have trouble authenticating on an NIS client, it may be due to a differing password format. In a heterogeneous network, the format must be supported by all operating systems, where DES is the lowest common standard.

To check which format a server or client is using, look at this section of /etc/login.conf:

In this example, the system is using the DES format. Other possible values are blf for Blowfish and md5 for MD5 encrypted passwords.

If the format on a host needs to be edited to match the one being used in the NIS domain, the login capability database must be rebuilt after saving the change:

LDAP 使用了數個術語在開始設置之前必須先了解。所有的目錄項目由一群屬性 (attributes) 所組成，每個屬性集皆有一個獨特的辨識碼稱為辨識名稱 (Distinguished Name, DN)，這個辨識碼會由數個其他的屬性，如：常用或相對辨識名稱 (Relative Distinguished Name, RDN) 所組成，這就像目錄有絕對路徑與相對路徑，可以把 DN 當做絕對路徑，RDN 當做相對路徑。

LDAP 項目的例子如下。這個例子會搜尋指定使用者帳號 (uid)、組織單位 (ou) 及組織的項目 (o)：

這個範例項目會顯示 dn, mail, cn, uid 以及 telephoneNumber 屬性的數值。而 cn 屬性則是 RDN。

更多有關 LDAP 以及其術語的資訊可在 http://www.openldap.org/doc/admin24/intro.html 找到。

FreeBSD 並未提供內建的 LDAP 伺服器，要開始設定前請先安裝 net/openldap-server 套件或 Port：

在套件中已開啟了許多的預設選項，可以透過執行 pkg info openldap-server 來查看已開啟的選項，若有不足的地方 (例如需要開啟 SQL 的支援)，請考慮使用適當的方式重新編譯該 Port。

安裝程序會建立目錄 /var/db/openldap-data 來儲存資料，同時需要建立儲存憑證的目錄：

接下來是設定憑証機構 (Certificate authority)。以下指令必須在 /usr/local/etc/openldap/private 下執行，這很重要是由於檔案權限須要被限制且其他使用者不應有這些檔案的存取權限，更多有關憑証的詳細資訊以及相關的參數可在 OpenSSL 中找到。要建立憑証授權，需先輸人這個指令並依提示操作：

提示輸入的項目除了通用名稱 (Common Name) 外其他是可以一樣的，這個項目必須使用跟系統主機名稱 不同 的名稱。若這是一個自行簽署的憑証 (Self signed certificate)，則在憑証機構 CA 的前面加上主機名稱。

接下來的工作是建立一個伺服器的憑証簽署請求與一個私鑰。請輸入以下指令然後依提示操作：

在憑証產生程序的過程中請確認 Common Name 屬性設定正確。憑証簽署請求 (Certificate Signing Request) 必須經過憑証機構簽署後才會成為有效的憑証：

在憑証產生程序的最後一步是產生並簽署客戶端憑証：

記得當提示時要使用同樣的 Common Name 屬性。完成之後，請確認執行的指令產生了 8 個新檔案。

OpenLDAP 伺服器所執行的 Daemon 為 slapd，OpenLDAP 是透過 slapd.ldif 來做設定， OpenLDAP 官方已停止採用舊的 slapd.conf 格式。

這裡有些 slapd.ldif 的 設定檔範例 可以使用，同時您也可以在 /usr/local/etc/openldap/slapd.ldif.sample 找到範例資訊。相關可用的選項在 slapd-config(5) 文件會有說明。slapd.ldif 的每個段落，如同其他 LDAP 屬性設定一樣會透過獨一無二 DN 來辨識，並請確保 dn: 描述與其相關屬性之間沒有空行。以下的範例中會實作一個使用 TLS 的安全通道，首先是全域的設定：

這個檔案中必須指定憑証機構 (Certificate Authority)、伺服器憑証 (Server Certificate) 與伺服器私鑰 (Server Private Key)，建議可讓客戶端決定使用的安全密碼 (Security Cipher)，略過 olcTLSCipherSuite 選項 (此選項不相容 openssl 以外的 TLS 客戶端)。選項 olcTLSProtocolMin 讓伺服器可要求一個安全等級的最低限度，建議使用。伺服器有進行驗証的必要，但客戶端並不需要，因此可設定 olcTLSVerifyClient: never。

第二個部份是設定後端要採用的模組有那些，可使用以下方式設定：

第三個部份要載入資料庫所需的 ldif 綱要 (Schema)，這個動作是必要的。

接下來是前端設定的部份：

再來是設定後端的部份，之後唯一能夠存取 OpenLDAP 伺服器設定的方式是使用全域超級使用者。

預設的管理者使用者名稱是 cn=config，可在 Shell 中輸入 slappasswd，決定要使用的密碼並將其產生的編碼放到 olcRootPW 欄位中。若這個選項在這時沒有設定好，在匯入 slapd.ldif 之後將沒有任何人有辦法修改全域的設定。

最後一個部份是有關資料庫後端的設定：

這裡指定的資料庫即實際用來保存LDAP 目錄的資料，也可以使用 mdb 以外的項目，資料庫的超級使用者可在這裡設定 (與全域的超級使用者是不同的東西)：olcRootDN　需填寫使用者名稱 (可自訂)，olcRootPW 需填寫該使用者編碼後的密碼，將密碼編碼可使用 slappasswd 如同前面所述。

這裡有個檔案庫內有四個 slapd.ldif 的範例，要將現有的 slapd.conf 轉換成 slapd.ldif 格式，可參考此頁 (注意，這裡面的說明也會介紹一些不常用的選項)。

當設定完成之後，需將 slapd.ldif 放在一個空的目錄當中，建議如以下方式建立：

匯入設定資料庫：

啟動 slapd Daemon：

選項 -d 可以用來除錯使用，如同 slapd(8) 中所說明的，若要檢驗伺服器是否正常執行與運作可以：

伺服器端仍必須受到信任，若在此之前未做過這個動作，請依照以下指示操作。安裝 OpenSSL 套件或 Port：

進入 ca.crt 所在的目錄 (以這邊使用的例子來說則是 /usr/local/etc/openldap)，執行：

現在 CA 與伺服器憑証可以依其用途被辨識，可進入 server.crt 所在的目錄執行以下指令來檢查：

若 slapd 已正在執行，就重新啟動它。如同 /usr/local/etc/rc.d/slapd 所述，要讓 slapd 開機時可正常執行，須要加入以下行到 /etc/rc.conf：

開機啟動 slapd 並不會提供除錯的功能，您可以檢查 /var/log/debug.log, dmesg -a 及 /var/log/messages 檢確認是否有正常運作。

以下範例會新增群組 team 及使用者 john 到 domain.example LDAP 資料庫，而該資料庫目前是空的。首先要先建立 domain.ldif 檔：

請查看 OpenLDAP 說明文件取得更詳細的資訊，使用 slappasswd 來將純文字的密碼 secret 更改為已編碼的型式來填寫 userPassword 欄位。在 loginShell 所指定的路徑，必須在所有可讓 john 登入的系統中存在。最後是使用 mdb 管理者修改資料庫：

要修改全域設定只能使用全域的超及使用者。例如，假設一開始採用了 olcTLSCipherSuite: HIGH:MEDIUM:SSLv3 選項，但最後想要把它移除，可以建立一個有以下內容的檔案：

然後套用修改內容：

當提示輸入密碼時，提供當時在設定後端一節所設定的密碼，在這裡無須填寫使用者名稱，cn=config 代表要修改資料庫資料的位置。也可以使用 ldapmodify 刪除其中一行屬性，或是 ldapdelete 刪除整筆資料。

若有問題無法正常執行，或是全域的超級使用者無法存取後端的設定，可以刪除並重建整個後端設定：

可以修改 slapd.ldif 後再重新匯入一次。請注意，這個步驟只在沒有其他方式可用時才使用。

本章節的設定說明只針對伺服器端的部份，在同一台主機中也可以同時有安裝 LDAP 客戶端但需要額外做設定。

DHCP 客戶端內含在 FreeBSD 安裝程式當中，這讓在新安裝的系統上設定自動從 DHCP 伺服器接收網路位置資訊變的更簡單。請參考 安裝後注意事項 取得網路設置的範例。

當 dhclient 在客戶端機器上執行時，它便會開始廣播請求取得設置資訊。預設這些請求會使用 UDP 埠號 68。而伺服器則會在 UDP 埠號 67 來回覆，將 IP 位址與其他相關的網路資訊，如：子網路遮罩、預設閘道及 DNS 伺服器位址告訴客戶端，詳細的清單可在 dhcp-options(5) 找到。

預設當 FreeBSD 系統開機時，其 DHCP 客戶端會在背景執行或稱非同步 (Asynchronously) 執行，在完成 DHCP 程序的同時其他啟動 Script 會繼續執行，來加速系統啟動。

背景 DHCP 在 DHCP 伺服器可以快速的回應客戶端請求時可運作的很好。然而 DHCP 在某些系統可能需要較長的時間才能完成，若網路服務嘗試在 DHCP 尚未分配網路位置資訊前執行則會失敗。使用同步 (Synchronous) 模式執行 DHCP 可避免這個問題，因為同步模式會暫停啟動直到 DHCP 已設置完成。

在 /etc/rc.conf 中的這行用來設定採用背景 (非同步模式)：

若系統已經在安裝時設定使用 DHCP，這行可能會已存在。替換在例子中的 fxp0 為實際要動態設置的網路介面名稱，如 設定網路介面卡 中的說明。

要改設定系統採用同步模式，在啟動時暫停等候 DHCP 完成，使用 “SYNCDHCP”：

尚有其他可用的客戶端選項，請在 rc.conf(5) 搜尋 dhclient 來取得詳細資訊。

DHCP 客戶端會使用到以下檔案：

本節將示範如何設定 FreeBSD 系統成為 DHCP 伺服器，使用 Internet Systems Consortium (ISC) 所實作的 DHCP 伺服器，這個伺服器及其文件可使用 net/isc-dhcp44-server 套件或 Port 安裝。

net/isc-dhcp44-server 的安裝程式會安裝一份範例設定檔，複製 /usr/local/etc/dhcpd.conf.example 到 /usr/local/etc/dhcpd.conf 並在這個新檔案做編輯。

這個設定檔內容包括了子網路及主機的宣告，用來定義要提供給 DHCP 客戶端的資訊。如以下行設定：

此設定檔還支援其他選項，請參考隨伺服器一併安裝的 dhcpd.conf(5) 來取得詳細資訊與範例。

完成 dhcpd.conf 的設定之後，在 /etc/rc.conf 啟動 DHCP 伺服器：

替換 dc0 為 DHCP 伺服器要傾聽 DHCP 客戶端請求的網路介面 (多個介面可以空白分隔)。

執行以下指令來啟動伺服器：

往後任何對伺服器設定的變更會需要使用 service(8) 中止 dhcpd 服務然後啟動。

DHCP 伺服器會使用到以下檔案。注意，操作手冊會與伺服器軟體一同安裝。

名稱伺服器通常有兩種形式：有權的 (Authoritative) 名稱伺服器與快取 (或稱解析) 名稱伺服器。

以下情況會需要一台有權的名稱伺服器：

以下情況會需要一台快取名稱伺服器：

當查詢 www.FreeBSD.org 時，解析程式通常會查詢上游 ISP 的名稱伺服器然後接收其回覆，使用本地、快取 DNS 伺服器，只需要由快取 DNS 伺服器對外部做一次查詢，其他的查詢則不需要再向區域網路之外查詢，因為這些資訊已經在本地被快取了。

Unbound 由 FreeBSD 基礎系統提供，預設只會提供本機的 DNS 解析，雖然基礎系統的套件可被設定提供本機以外的解析服務，但要解決這樣的需求仍建議安裝 FreeBSD Port 套件集中的 Unbound。

要開啟 Unbound 可加入下行到 /etc/rc.conf：

任何已存在於 /etc/resolv.conf 中的名稱伺服器會在新的 Unbound 設定中被設為追隨者 (Forwarder)。

確認完每一台名稱伺服器都支援 DNSSEC 後啟動 Unbound：

這將會更新 /etc/resolv.conf 來讓查詢已用 DNSSEC 確保安全的網域現在可以運作，例如，執行以下指令來檢驗 FreeBSD.org DNSSEC 信任樹：

在 FreeBSD 中，主 Apache HTTP Server 設定檔會安裝於 /usr/local/etc/apache2x/httpd.conf，其中 x 代表版號，這份 ASCII 文字檔中以 # 做為行首的是註解，而最常需修改的項目有：

在對 Apache 設定檔做變更之前，建議先做備份，在 Apache 設定完成之後，儲存讓檔案並使用 apachectl 檢驗設定，執行 apachectl configtest 的結果應回傳 Syntax OK。

要在系統啟動時執行 Apache，可加入下行到 /etc/rc.conf：

若 Apache 要使用非預設的選項啟動，可加入下行到 /etc/rc.conf 來指定所需的旗標參數：

若 apachectl 未回報設定錯，則可啟動 httpd：

httpd 服務可以透過在網頁瀏覽器中輸入 http://localhost 來測試，將 localhost 更改為執行 httpd 那台主機的完整網域名稱 (Fully-qualified domain name)。預設會顯示的網頁為 /usr/local/www/apache24/data/index.html。

後續若有在 httpd 執行中時修改 Apache 設定檔可使用以下指令來測試是否有誤：

虛擬主機允許在一個 Apache 伺服器執行多個網站，虛擬主機可以是以 IP 為主 (IP-based) 或以名稱為主 (name-based)。以 IP 為主的虛擬主機中的每一個網站要使用不同的 IP 位址。以名稱為主的虛擬主機會使用客戶端的 HTTP/1.1 標頭來判斷主機名稱，這可讓不同的網站共用相同的 IP 位址。

要設定 Apache 使用以名稱為主的虛擬主機可在每一個網站加入 VirtualHost 區塊，例如，有一個名稱為 www.domain.tld 的主機擁有一個 www.someotherdomain.tld 的虛擬網域，可加入以下項目到 httpd.conf：

每一個虛擬主機均需更改其 ServerName 與 DocumentRoot 的值為實際要使用的值。

更多有關設定虛擬主機的資訊，可參考 Apache 官方說明文件於：http://httpd.apache.org/docs/vhosts/。

Apache 使用模組 (Module) 來擴充伺服器所提供的功能。請參考 http://httpd.apache.org/docs/current/mod/ 來取得可用模組的完整清單與設定詳細資訊。

在 FreeBSD 中有些模組可以隨著 www/apache24 Port 編譯，只要在 /usr/ports/www/apache24 輸入 make config 便可查看有那一些模組是預設開啟的，若模組未與 Port 一併編譯，FreeBSD Port 套件集也提供了一個簡單的方式可安裝各種模組，本節將介紹最常使用的三個模組。

除了 mod_perl 與 mod_php 外，也有其他語言可用來建立動態網頁內容，這包含了 Django 與 Ruby on Rails。

最重要的一個設定步驟便是決定那些帳號能夠存取 FTP 伺服器，FreeBSD 系統有數個系統帳號，這些帳號不應該能夠擁有 FTP 存取權，不允許存取 FTP 的使用者清單可在 /etc/ftpusers 找到，預設該檔案內會有所有的系統帳號，其他不應允許存取 FTP 的使用者也可在此加入。

在某些情況可能會布望限制某些使用者的存取，而不是完全避免這些使用者使用 FTP，這可以透過建立 /etc/ftpchroot 來完成，詳如 ftpchroot(5) 所述，這個檔案會列出受到 FTP 存取限制的使用者與群組。

要在伺服器上開啟匿名 FTP 存取權，可在 FreeBSD 系統上建立一個名稱為 ftp 使用者，使用者將能夠使用 ftp 或 anonymous 使用者名稱來登入 FTP 伺服器，當提示輸入密碼時，輸入任何值都會被接受，但是慣例上應使用電子郵件位址來當做密碼。當匿名使用者登入時 FTP 伺服器會呼叫 chroot(2) 來限制使用者只能存取 ftp 使用者的家目錄。

要設定顯示給 FTP 客戶端的歡迎訊息有兩個文字檔可以建立，/etc/ftpwelcome 的內容會在收到登入提示前顯示給使用者看，登入成功能後，則會顯示 /etc/ftpmotd 的內容。注意，這個檔案的路徑是相對於登入環境的，所以 ~ftp/etc/ftpmotd 的內容只會對匿名使用者顯示。

設定完 FTP 伺服器之後，在 /etc/rc.conf 設定適當的變數來在開機時啟動該服務：

要立即啟動服務可：

要測試到 FTP 伺服器的連線可輸入：

ftpd daemon 會使用 syslog(3) 來記錄訊息，預設，系統記錄 Daemon 會寫入有關 FTP 的訊息到 /var/log/xferlog，FTP 記錄的位置可以透過更改 /etc/syslog.conf 中下行來做修改：

Samba 的設定位於 /usr/local/etc/smb4.conf，必須先設定這個檔案才可使用 Samba。

要共享目錄與印表機給在工作群組中的 Windows™ 客戶端的簡易 smb4.conf 範例如下。對於涉及 LDAP 或 Active Directory 的複雜安裝，可使用 samba-tool(8) 來建立初始的 smb4.conf。

要在開機時啟動 Samba，可加入下行到 /etc/rc.conf：

要立即啟動 Samba：

Samba 由三個獨立的 Daemon 所組成，nmbd 與 smbd daemon 可透過 samba_enable 來啟動，若同時也需要 winbind 名稱解析服務則需額外設定：

Samba 可以隨時停止，要停止可輸入：

Samba 是一套擁有能整合 Microsoft™ Windows™ 網路功能的複雜軟體套件，除了在此處說明的基礎設定，要取得更多的功能資訊，請參考 http://www.samba.org。

在 FreeBSD，內建的 ntpd 可用來同步系統的時間，Ntpd 要使用 rc.conf(5) 中的變數以及下一節會詳細說明的 /etc/ntp.conf 來設定。

Ntpd 與網路中各節點的通訊採用 UDP 封包，在伺服器與 NTP 各節點間的防火牆必須設定成可允許進/出埠 123 的 UDP 封包。

ntpd 並不需要永久的網際網路連線才能正常運作，若有一個 PPP 連線是設定成需要時撥號，那麼便需要避免 NTP 的流量觸發撥號或是保持連線不中斷，這可在 /etc/ppp/ppp.conf 使用 filter 項目設定，例如：

要取得更詳細的資訊，請參考於 ppp(8) 的 PACKET FILTERING 小節以及在 /usr/shared/examples/ppp/ 中的範例。

To configure an iSCSI target, create the /etc/ctl.conf configuration file, add a line to /etc/rc.conf to make sure the ctld(8) daemon is automatically started at boot, and then start the daemon.

The following is an example of a simple /etc/ctl.conf configuration file. Refer to ctl.conf(5) for a more complete description of this file’s available options.

The first entry defines the pg0 portal group. Portal groups define which network addresses the ctld(8) daemon will listen on. The discovery-auth-group no-authentication entry indicates that any initiator is allowed to perform iSCSI target discovery without authentication. Lines three and four configure ctld(8) to listen on all IPv4 (listen 0.0.0.0) and IPv6 (listen [::]) addresses on the default port of 3260.

It is not necessary to define a portal group as there is a built-in portal group called default. In this case, the difference between default and pg0 is that with default, target discovery is always denied, while with pg0, it is always allowed.

The second entry defines a single target. Target has two possible meanings: a machine serving iSCSI or a named group of LUNs. This example uses the latter meaning, where iqn.2012-06.com.example:target0 is the target name. This target name is suitable for testing purposes. For actual use, change com.example to the real domain name, reversed. The 2012-06 represents the year and month of acquiring control of that domain name, and target0 can be any value. Any number of targets can be defined in this configuration file.

The auth-group no-authentication line allows all initiators to connect to the specified target and portal-group pg0 makes the target reachable through the pg0 portal group.

The next section defines the LUN. To the initiator, each LUN will be visible as a separate disk device. Multiple LUNs can be defined for each target. Each LUN is identified by a number, where LUN 0 is mandatory. The path /data/target0-0 line defines the full path to a file or zvol backing the LUN. That path must exist before starting ctld(8). The second line is optional and specifies the size of the LUN.

Next, to make sure the ctld(8) daemon is started at boot, add this line to /etc/rc.conf:

To start ctld(8) now, run this command:

As the ctld(8) daemon is started, it reads /etc/ctl.conf. If this file is edited after the daemon starts, use this command so that the changes take effect immediately:

The iSCSI initiator requires that the iscsid(8) daemon is running. This daemon does not use a configuration file. To start it automatically at boot, add this line to /etc/rc.conf:

To start iscsid(8) now, run this command:

Connecting to a target can be done with or without an /etc/iscsi.conf configuration file. This section demonstrates both types of connections.