diff --git a/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml b/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml index d402890e50..26dba92958 100644 --- a/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml +++ b/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml @@ -1,6247 +1,5883 @@ Advanced Networking Synopsis - This chapter will cover a number of advanced networking + This chapter covers a number of advanced networking topics. After reading this chapter, you will know: The basics of gateways and routes. How to set up &ieee; 802.11 and &bluetooth; devices. - How to make FreeBSD act as a bridge. + How to make &os; act as a bridge. How to set up network booting on a diskless machine. - How to set up network PXE booting with an NFS root file - system. + How to set up network PXE booting + with an + NFS root file system. How to set up network address translation. - How to set up IPv6 on a FreeBSD machine. + How to set up IPv6 on a &os; + machine. - How to configure ATM. + How to configure ATM. - How to enable and utilize the features of CARP, the - Common Address Redundancy Protocol in &os; + How to enable and utilize the features of the Common + Address Redundancy Protocol (CARP) in + &os;. Before reading this chapter, you should: Understand the basics of the /etc/rc scripts. Be familiar with basic network terminology. - Know how to configure and install a new FreeBSD kernel + Know how to configure and install a new &os; kernel (). - Know how to install additional third-party - software (). + Know how to install additional third-party software + (). Coranth Gryphon Contributed by Gateways and Routes routing gateway subnet For one machine to be able to find another over a network, there must be a mechanism in place to describe how to get from one to the other. This is called routing. A route is a defined pair of addresses: a destination and a - gateway. The pair indicates that if you are - trying to get to this destination, - communicate through this gateway. There - are three types of destinations: individual hosts, subnets, and + gateway. The pair indicates that when trying + to get to this destination, communicate + through this gateway. There are three + types of destinations: individual hosts, subnets, and default. The default route is - used if none of the other routes apply. We will talk a little - bit more about default routes later on. There are also three + used if none of the other routes apply. There are also three types of gateways: individual hosts, interfaces (also called - links), and Ethernet hardware addresses (MAC - addresses). + links), and Ethernet hardware + (MAC) addresses. An Example - To illustrate different aspects of routing, we will use - the following example from netstat: + This example &man.netstat.1; output illustrates several + aspects of routing: &prompt.user; netstat -r Routing tables Destination Gateway Flags Refs Use Netif Expire default outside-gw UGSc 37 418 ppp0 localhost localhost UH 0 181 lo0 test0 0:e0:b5:36:cf:4f UHLW 5 63288 ed0 77 10.20.30.255 link#1 UHLW 1 2421 example.com link#1 UC 0 0 host1 0:e0:a8:37:8:1e UHLW 3 4601 lo0 host2 0:e0:a8:37:8:1e UHLW 0 5 lo0 => host2.example.com link#1 UC 0 0 224 link#1 UC 0 0 default route - The first two lines specify the default route (which we - will cover in the - next section) + The first two lines specify the default route, described + in more detail in , and the localhost route. loopback device The interface (Netif column) that this routing table specifies to use for localhost is lo0, also known as the loopback device. This says to keep all traffic for this destination internal, rather than sending it - out over the LAN, since it will only end up back where it - started. + out over the network. Ethernet MAC address - The next thing that stands out are the addresses beginning - with 0:e0:. These are Ethernet - hardware addresses, which are also known as MAC addresses. - FreeBSD will automatically identify any hosts - (test0 in the example) on the local Ethernet - and add a route for that host, directly to it over the - Ethernet interface, ed0. There is - also a timeout (Expire column) associated - with this type of route, which is used if we fail to hear from - the host in a specific amount of time. When this happens, the - route to this host will be automatically deleted. These hosts - are identified using a mechanism known as RIP (Routing - Information Protocol), which figures out routes to local hosts - based upon a shortest path determination. + The addresses beginning with 0:e0: are Ethernet hardware addresses, + also known as MAC addresses. &os; will + automatically identify any hosts, test0 in + the example, on the local Ethernet and add a route for that + host over the Ethernet interface, + ed0. This type of route has a + timeout, seen in the Expire column, which + is used if the host does not respond in a specific amount of + time. When this happens, the route to this host will be + automatically deleted. These hosts are identified using the + Routing Information Protocol (RIP), which + calculates routes to local hosts based upon a shortest path + determination. subnet - FreeBSD will also add subnet routes for the local subnet - (10.20.30.255 is the broadcast - address for the subnet - 10.20.30, and - example.com is the domain - name associated with that subnet). The designation + &os; will add subnet routes for the local subnet. + 10.20.30.255 is the broadcast + address for the subnet 10.20.30 + and example.com is the + domain name associated with that subnet. The designation link#1 refers to the first Ethernet card in - the machine. You will notice no additional interface is - specified for those. - - Both of these groups (local network hosts and local - subnets) have their routes automatically configured by a - daemon called routed. If this is - not run, then only routes which are statically defined (i.e., - entered explicitly) will exist. - - The host1 line refers to our host, - which it knows by Ethernet address. Since we are the sending - host, FreeBSD knows to use the loopback interface - (lo0) rather than sending it out over - the Ethernet interface. - - The two host2 lines are an example of - what happens when we use an &man.ifconfig.8; alias (see the - section on Ethernet for reasons why we would do this). The + the machine. + + Local network hosts and local subnets have their routes + automatically configured by a daemon called &man.routed.8;. + If it is not running, only routes which are statically defined + by the administrator will exist. + + The host1 line refers to the host + by its Ethernet address. Since it is the sending host, &os; + knows to use the loopback interface + (lo0) rather than the Ethernet + interface. + + The two host2 lines represent aliases + which were created using &man.ifconfig.8;. The => symbol after the - lo0 interface says that not only are - we using the loopback (since this address also refers to the - local host), but specifically it is an alias. Such routes + lo0 interface says that an alias + has been set in addition to the loopback address. Such routes only show up on the host that supports the alias; all other - hosts on the local network will simply have a + hosts on the local network will have a link#1 line for such routes. - The final line (destination subnet - 224) deals with multicasting, - which will be covered in another section. + The final line (destination subnet 224) deals with + multicasting. Finally, various attributes of each route can be seen in the Flags column. Below is a short table of some of these flags and their meanings: U Up: The route is active. H Host: The route destination is a single host. G Gateway: Send anything for this destination on to this remote system, which will figure out from there where to send it. S Static: This route was configured manually, not automatically generated by the system. C Clone: Generates a new route based upon this - route for machines we connect to. This type of route + route for machines to connect to. This type of route is normally used for local networks. W WasCloned: Indicated a route that was auto-configured based upon a local area network (Clone) route. L Link: Route involves references to Ethernet hardware. Default Routes default route When the local system needs to make a connection to a remote host, it checks the routing table to determine if a known path exists. If the remote host falls into a subnet - that we know how to reach (Cloned routes), then the system - checks to see if it can connect along that interface. + that it knows how to reach, the system checks to see if it + can connect using that interface. If all known paths fail, the system has one last option: the default route. This route is a special type of gateway route (usually the only one present in the system), and is always marked with a c in the flags field. For hosts on a local area network, this - gateway is set to whatever machine has a direct connection to - the outside world (whether via PPP link, DSL, cable modem, T1, - or another network interface). + gateway is set to the system which has a direct connection to + the Internet. - If you are configuring the default route for a machine - which itself is functioning as the gateway to the outside - world, then the default route will be the gateway machine at - your Internet Service Provider's (ISP) site. + The default route for a machine which itself is + functioning as the gateway to the outside world, will be the + gateway machine at the Internet Service Provider + (ISP). - Let us look at an example of default routes. This is a - common configuration: + This example is a common configuration for a default + route: [Local2] <--ether--> [Local1] <--PPP--> [ISP-Serv] <--ether--> [T1-GW] The hosts Local1 and - Local2 are at your site. - Local1 is connected to an ISP via a dial up - PPP connection. This PPP server computer is connected through - a local area network to another gateway computer through an - external interface to the ISPs Internet feed. + Local2 are on the local network. + Local1 is connected to an + ISP using a + PPP connection. This + PPP server is connected through a local + area network to another gateway computer through an external + interface to the ISP. - The default routes for each of your machines will - be: + The default routes for each machine will be: Host Default Gateway Interface Local2 Local1 Ethernet Local1 T1-GW PPP - A common question is Why (or how) would we set - the T1-GW to be the default gateway for - Local1, rather than the ISP server it is - connected to?. - - Remember, since the PPP interface is using an address on - the ISP's local network for your side of the connection, - routes for any other machines on the ISP's local network will - be automatically generated. Hence, you will already know how + A common question is Why is + T1-GW configured as the default gateway for + Local1, rather than the + ISP server it is connected + to?. + + Since the PPP interface is using an + address on the ISP's local network for + the local side of the connection, routes for any other + machines on the ISP's local network will + be automatically generated. The system already knows how to reach the T1-GW machine, so there is no - need for the intermediate step of sending traffic to the ISP - server. - - It is common to use the address - X.X.X.1 as the gateway address - for your local network. So (using the same example), if your - local class-C address space was - 10.20.30 and your ISP was using - 10.9.9 then the default routes - would be: + need for the intermediate step of sending traffic to the + ISP's server. + + It is common to use the address X.X.X.1 as the gateway address for + the local network. So, if the local class C address space is + 10.20.30 and the + ISP is using 10.9.9, the default routes would + be: Host Default Route Local2 (10.20.30.2) Local1 (10.20.30.1) Local1 (10.20.30.1, 10.9.9.30) T1-GW (10.9.9.1) The default route can be easily defined in - /etc/rc.conf. In our example, on - the Local2 machine, we added the following - line in /etc/rc.conf: + /etc/rc.conf. In this example, on + Local2, add the following line to + /etc/rc.conf: defaultrouter="10.20.30.1" - It is also possible to do it directly from the command - line with the &man.route.8; command: + It is also possible to add the route directly using + &man.route.8;: &prompt.root; route add default 10.20.30.1 For more information on manual manipulation of network - routing tables, consult the &man.route.8; manual page. + routing tables, refer to &man.route.8;. Dual Homed Hosts dual homed hosts - There is one other type of configuration that we should - cover, and that is a host that sits on two different networks. - Technically, any machine functioning as a gateway (in the - example above, using a PPP connection) counts as a dual-homed - host. But the term is really only used to refer to a machine - that sits on two local-area networks. - - In one case, the machine has two Ethernet cards, each - having an address on the separate subnets. Alternately, the - machine may only have one Ethernet card, and be using - &man.ifconfig.8; aliasing. The former is used if two - physically separate Ethernet networks are in use, the latter - if there is one physical network segment, but two logically - separate subnets. + A a dual-homed system is a host which resides on two + different networks. + + The dual-homed machine might have two Ethernet cards, each + having an address on a separate subnet. Alternately, the + machine can have one Ethernet card and uses &man.ifconfig.8; + aliasing. The former is used if two physically separate + Ethernet networks are in use and the latter if there is one + physical network segment, but two logically separate + subnets. Either way, routing tables are set up so that each subnet knows that this machine is the defined gateway (inbound route) to the other subnet. This configuration, with the machine - acting as a router between the two subnets, is often used when - we need to implement packet filtering or firewall security in + acting as a router between the two subnets, is often used + to implement packet filtering or firewall security in either or both directions. - If you want this machine to actually forward packets - between the two interfaces, you need to tell FreeBSD to enable - this ability. See the next section for more details on how - to do this. + For this machine to forward packets between the two + interfaces, &os; must be configured as a router, as + demonstrated in the next section. Building a Router router - A network router is simply a system that forwards packets - from one interface to another. Internet standards and good - engineering practice prevent the FreeBSD Project from enabling - this by default in FreeBSD. You can enable this feature by + A network router is a system that forwards packets from + one interface to another. Internet standards and good + engineering practice prevent the &os; Project from enabling + this by default in &os;. This feature can be enabled by changing the following variable to YES in &man.rc.conf.5;: gateway_enable="YES" # Set to YES if this host will be a gateway This option will set the &man.sysctl.8; variable net.inet.ip.forwarding to - 1. If you should need to stop routing - temporarily, you can reset this to 0 - temporarily. + 1. To stop routing, reset this to + 0. BGP RIP OSPF - Your new router will need routes to know where to send the - traffic. If your network is simple enough you can use static - routes. FreeBSD also comes with the standard BSD routing - daemon &man.routed.8;, which speaks RIP (both version 1 and - version 2) and IRDP. Support for BGP v4, OSPF v2, and other + The new router will need routes to know where to send the + traffic. If the network is simple enough, static routes can + be used. &os; comes with the standard BSD routing daemon + &man.routed.8;, which speaks RIP versions + 1 and 2, and IRDP. Support for + BGPv4, OSPFv2, and other sophisticated routing protocols is available with the - net/zebra package. - Commercial products such as &gated; - are also available for more complex network routing - solutions. + net/zebra package or + port. Al Hoang Contributed by Setting Up Static Routes Manual Configuration - Let us assume we have a network as follows: + Consider the following network: INTERNET | (10.0.0.1/24) Default Router to Internet | |Interface xl0 |10.0.0.10/24 +------+ | | RouterA | | (FreeBSD gateway) +------+ | Interface xl1 | 192.168.1.1/24 | +--------------------------------+ Internal Net 1 | 192.168.1.2/24 | +------+ | | RouterB | | +------+ | 192.168.2.1/24 | Internal Net 2 - In this scenario, RouterA is our &os; + In this scenario, RouterA is a &os; machine that is acting as a router to the rest of the - Internet. It has a default route set to - 10.0.0.1 which allows it to - connect with the outside world. We will assume that - RouterB is already configured properly and - knows how to get wherever it needs to go. (This is simple - in this picture. Just add a default route on - RouterB using - 192.168.1.1 as the - gateway.) - - If we look at the routing table for - RouterA we would see something like the - following: + Internet. It has a default route set to 10.0.0.1 which allows it to + connect with the outside world. RouterB is + already configured properly as it uses 192.168.1.1 as the gateway. + + The routing table on RouterA looks + something like this: &prompt.user; netstat -nr Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 10.0.0.1 UGS 0 49378 xl0 127.0.0.1 127.0.0.1 UH 0 6 lo0 10.0.0.0/24 link#1 UC 0 0 xl0 192.168.1.0/24 link#2 UC 0 0 xl1 - With the current routing table RouterA - will not be able to reach our Internal Net 2. It does not - have a route for - 192.168.2.0/24. One way to - alleviate this is to manually add the route. The following - command would add the Internal Net 2 network to - RouterA's routing table using - 192.168.1.2 as the next + With the current routing table, RouterA + cannot reach Internal Net 2 as it does not have a route for + 192.168.2.0/24. The + following command adds the Internal Net 2 network to + RouterA's routing table using 192.168.1.2 as the next hop: &prompt.root; route add -net 192.168.2.0/24 192.168.1.2 Now RouterA can reach any hosts on the 192.168.2.0/24 network. Persistent Configuration - The above example is perfect for configuring a static - route on a running system. However, one problem is that the - routing information will not persist if you reboot your &os; - machine. Additional static routes can be - entered in /etc/rc.conf: + The above example configures a static route on a + running system. However, the routing information will not + persist if the &os; system reboots. Persistent static + routes can be entered in + /etc/rc.conf: # Add Internal Net 2 as a static route static_routes="internalnet2" route_internalnet2="-net 192.168.2.0/24 192.168.1.2" The static_routes configuration - variable is a list of strings separated by a space. Each - string references to a route name. In our above example we - only have one string in static_routes. - This string is internalnet2. We - then add a configuration variable called + variable is a list of strings separated by a space, where + each string references a route name. This example only + has one string in static_routes, + internalnet2. The variable route_internalnet2 - where we put all of the configuration parameters we would - give to the &man.route.8; command. For our example above we - would have used the command: + contains all of the configuration parameters to + &man.route.8;. This example is equivalent to the + command: &prompt.root; route add -net 192.168.2.0/24 192.168.1.2 - so we need "-net 192.168.2.0/24 - 192.168.1.2". - - As said above, we can have more than one string in - static_routes. This allows us to create - multiple static routes. The following lines shows an - example of adding static routes for the - 192.168.0.0/24 and - 192.168.1.0/24 networks on an - imaginary router: + Using more than one string in + static_routes creates multiple static + routes. The following shows an example of adding static + routes for the 192.168.0.0/24 + and 192.168.1.0/24 + networks: static_routes="net1 net2" route_net1="-net 192.168.0.0/24 192.168.0.1" route_net2="-net 192.168.1.0/24 192.168.1.1" Routing Propagation - routing propagation - We have already talked about how we define our routes to - the outside world, but not about how the outside world finds - us. - - We already know that routing tables can be set up so that - all traffic for a particular address space (in our examples, a - class-C subnet) can be sent to a particular host on that - network, which will forward the packets inbound. - - When you get an address space assigned to your site, your - service provider will set up their routing tables so that all - traffic for your subnet will be sent down your PPP link to - your site. But how do sites across the country know to send - to your ISP? - - There is a system (much like the distributed DNS - information) that keeps track of all assigned address-spaces, - and defines their point of connection to the Internet - Backbone. The Backbone are the main trunk - lines that carry Internet traffic across the country, and - around the world. Each backbone machine has a copy of a - master set of tables, which direct traffic for a particular - network to a specific backbone carrier, and from there down - the chain of service providers until it reaches your - network. - - It is the task of your service provider to advertise to - the backbone sites that they are the point of connection (and - thus the path inward) for your site. This is known as route + When an address space is assigned to a network, the + service provider configures their routing tables so that all + traffic for the network will be sent to the link for the + site. But how do external sites know to send their packets + to the network's ISP? + + There is a system that keeps track of all assigned + address spaces and defines their point of connection to the + Internet backbone, or the main trunk lines that carry Internet + traffic across the country and around the world. Each + backbone machine has a copy of a master set of tables, which + direct traffic for a particular network to a specific + backbone carrier, and from there down the chain of service + providers until it reaches your network. + + It is the task of the service provider to advertise to + the backbone sites that they are the point of connection, and + thus the path inward, for a site. This is known as route propagation. Troubleshooting - traceroute + &man.traceroute.8; - Sometimes, there is a problem with routing propagation, - and some sites are unable to connect to you. Perhaps the most + Sometimes, there is a problem with routing propagation + and some sites are unable to connect. Perhaps the most useful command for trying to figure out where routing is - breaking down is the &man.traceroute.8; command. It is - equally useful if you cannot seem to make a connection to a - remote machine (i.e., &man.ping.8; fails). + breaking down is &man.traceroute.8;. It is useful when + &man.ping.8; fails. - The &man.traceroute.8; command is run with the name of the - remote host you are trying to connect to. It will show the - gateway hosts along the path of the attempt, eventually either + When using &man.traceroute.8;, include the name of the + remote host to connect to. The output will show the gateway + hosts along the path of the attempt, eventually either reaching the target host, or terminating because of a lack of connection. - For more information, see the manual page for - &man.traceroute.8;. + For more information, refer to &man.traceroute.8;. Multicast Routing multicast routing kernel options MROUTING - FreeBSD supports both multicast applications and multicast - routing natively. Multicast applications do not require any - special configuration of FreeBSD; applications will generally - run out of the box. Multicast routing - requires that support be compiled into the kernel: + &os; natively supports both multicast applications and + multicast routing. Multicast applications do not require any + special configuration of &os;; as applications will generally + run out of the box. Multicast routing requires that support + be compiled into a custom kernel: options MROUTING - In addition, the multicast routing daemon, &man.mrouted.8; - must be configured to set up tunnels and - DVMRP via + The multicast routing daemon, &man.mrouted.8;, must be + configured to set up tunnels and DVMRP via /etc/mrouted.conf. More details on - multicast configuration may be found in the manual page for + multicast configuration may be found in &man.mrouted.8;. The &man.mrouted.8; multicast routing daemon implements the DVMRP multicast routing protocol, which has largely been replaced by &man.pim.4; in many multicast installations. &man.mrouted.8; and the related &man.map-mbone.8; and &man.mrinfo.8; utilities are available - in the &os; Ports Collection as - net/mrouted. + in the &os; Ports Collection as net/mrouted. Loader Marc Fonvieille Murray Stokely Wireless Networking wireless networking 802.11 wireless networking Wireless Networking Basics Most wireless networks are based on the &ieee; 802.11 standards. A basic wireless network consists of multiple stations communicating with radios that broadcast in either - the 2.4GHz or 5GHz band (though this varies according to the + the 2.4GHz or 5GHz band, though this varies according to the locale and is also changing to enable communication in the - 2.3GHz and 4.9GHz ranges). - - 802.11 networks are organized in two ways: in - infrastructure mode one station acts as a - master with all the other stations associating to it; the - network is known as a BSS and the master station is termed an - access point (AP). In a BSS all communication passes through - the AP; even when one station wants to communicate with - another wireless station messages must go through the AP. In - the second form of network there is no master and stations - communicate directly. This form of network is termed an IBSS - and is commonly known as an - ad-hoc network. + 2.3GHz and 4.9GHz ranges. + + 802.11 networks are organized in two ways. In + infrastructure mode, one station acts as + a + master with all the other stations associating to it, the + network is known as a BSS, and the master + station is termed an access point (AP). + In a BSS, all communication passes through + the AP; even when one station wants to + communicate with another wireless station, messages must go + through the AP. In the second form of + network, there is no master and stations communicate directly. + This form of network is termed an IBSS + and is commonly known as an ad-hoc + network. 802.11 networks were first deployed in the 2.4GHz band using protocols defined by the &ieee; 802.11 and 802.11b standard. These specifications include the operating - frequencies, MAC layer characteristics including framing and - transmission rates (communication can be done at various - rates). Later the 802.11a standard defined operation in the - 5GHz band, including different signalling mechanisms and - higher transmission rates. Still later the 802.11g standard - was defined to enable use of 802.11a signalling and - transmission mechanisms in the 2.4GHz band in such a way as to - be backwards compatible with 802.11b networks. - - Separate from the underlying transmission techniques + frequencies and the MAC layer + characteristics, including framing and transmission rates, + as communication can occur at various rates. Later, the + 802.11a standard defined operation in the 5GHz band, including + different signaling mechanisms and higher transmission rates. + Still later, the 802.11g standard defined the use of 802.11a + signaling and transmission mechanisms in the 2.4GHz band in + such a way as to be backwards compatible with 802.11b + networks. + + Separate from the underlying transmission techniques, 802.11 networks have a variety of security mechanisms. The original 802.11 specifications defined a simple security - protocol called WEP. This protocol uses a fixed pre-shared key - and the RC4 cryptographic cipher to encode data transmitted on - a network. Stations must all agree on the fixed key in order - to communicate. This scheme was shown to be easily broken and - is now rarely used except to discourage transient users from - joining networks. Current security practice is given by the - &ieee; 802.11i specification that defines new cryptographic - ciphers and an additional protocol to authenticate stations to - an access point and exchange keys for doing data - communication. Further, cryptographic keys are periodically - refreshed and there are mechanisms for detecting intrusion - attempts (and for countering intrusion attempts). Another + protocol called WEP. This protocol uses a + fixed pre-shared key and the RC4 cryptographic cipher to + encode data transmitted on a network. Stations must all + agree on the fixed key in order to communicate. This scheme + was shown to be easily broken and is now rarely used except + to discourage transient users from joining networks. Current + security practice is given by the &ieee; 802.11i specification + that defines new cryptographic ciphers and an additional + protocol to authenticate stations to an access point and + exchange keys for data communication. Cryptographic keys + are periodically refreshed and there are mechanisms for + detecting and countering intrusion attempts. Another security protocol specification commonly used in wireless - networks is termed WPA. This was a precursor to 802.11i - defined by an industry group as an interim measure while - waiting for 802.11i to be ratified. WPA specifies a subset of - the requirements found in 802.11i and is designed for - implementation on legacy hardware. Specifically WPA requires - only the TKIP cipher that is derived from the original WEP - cipher. 802.11i permits use of TKIP but also requires support - for a stronger cipher, AES-CCM, for encrypting data. (The AES - cipher was not required in WPA because it was deemed too + networks is termed WPA, which was a + precursor to 802.11i. WPA specifies a + subset of the requirements found in 802.11i and is designed + for implementation on legacy hardware. Specifically, + WPA requires only the + TKIP cipher that is derived from the + original WEP cipher. 802.11i permits use + of TKIP but also requires support for a + stronger cipher, AES-CCM, for encrypting data. The + AES cipher was not required in + WPA because it was deemed too computationally costly to be implemented on legacy - hardware.) - - Other than the above protocol standards the other - important standard to be aware of is 802.11e. This defines - protocols for deploying multi-media applications such as - streaming video and voice over IP (VoIP) in an 802.11 network. - Like 802.11i, 802.11e also has a precursor specification - termed WME (later renamed WMM) that has been defined by an + hardware. + + The other standard to be aware of is 802.11e. It defines + protocols for deploying multimedia applications, such as + streaming video and voice over IP (VoIP), + in an 802.11 network. Like 802.11i, 802.11e also has a + precursor specification termed WME (later + renamed WMM) that has been defined by an industry group as a subset of 802.11e that can be deployed now - to enable multi-media applications while waiting for the final + to enable multimedia applications while waiting for the final ratification of 802.11e. The most important thing to know - about 802.11e and WME/WMM is that it enables prioritized - traffic use of a wireless network through Quality of Service - (QoS) protocols and enhanced media access protocols. Proper - implementation of these protocols enable high speed bursting - of data and prioritized traffic flow. - - &os; supports networks that operate - using 802.11a, 802.11b, and 802.11g. The WPA and 802.11i + about 802.11e and + WME/WMM is that it + enables prioritized traffic over a wireless network through + Quality of Service (QoS) protocols and + enhanced media access protocols. Proper implementation of + these protocols enables high speed bursting of data and + prioritized traffic flow. + + &os; supports networks that operate using 802.11a, + 802.11b, and 802.11g. The WPA and 802.11i security protocols are likewise supported (in conjunction with - any of 11a, 11b, and 11g) and QoS and traffic prioritization - required by the WME/WMM protocols are supported for a limited - set of wireless devices. + any of 11a, 11b, and 11g) and QoS and + traffic prioritization required by the + WME/WMM protocols are + supported for a limited set of wireless devices. Basic Setup Kernel Configuration - To use wireless networking, you need a wireless - networking card and to configure the kernel with the - appropriate wireless networking support. The latter is - separated into multiple modules so that you only need to - configure the software you are actually going to use. + To use wireless networking, a wireless networking card + is needed and the kernel needs to be configured with the + appropriate wireless networking support. The kernel is + separated into multiple modules so that only the required + support needs to be configured. - The first thing you need is a wireless device. The most - commonly used devices are those that use parts made by - Atheros. These devices are supported by the &man.ath.4; - driver and require the following line to be added to + The most + commonly used wireless devices are those that use parts made + by Atheros. These devices are supported by &man.ath.4; + and require the following line to be added to /boot/loader.conf: if_ath_load="YES" The Atheros driver is split up into three separate - pieces: the proper driver (&man.ath.4;), the hardware - support layer that handles chip-specific functions - (&man.ath.hal.4;), and an algorithm for selecting which of - several possible rates for transmitting frames - (ath_rate_sample here). When this support is loaded as - kernel modules, these dependencies are automatically handled - for you. If, instead of an Atheros device, you had another - device you would select the module for that device; - e.g.: + pieces: the driver (&man.ath.4;), the hardware support + layer that handles chip-specific functions + (&man.ath.hal.4;), and an algorithm for selecting the + rate for transmitting frames. When this support is loaded + as kernel modules, any dependencies are automatically + handled. To load support for a different type of wireless + device, specify the module for that device. This example + is for devices based on the Intersil Prism parts + (&man.wi.4;) driver: if_wi_load="YES" - for devices based on the Intersil Prism parts - (&man.wi.4; driver). - - In the rest of this document, we will use an - &man.ath.4; device, the device name in the examples must - be changed according to your configuration. A list of + The examples in this section use an &man.ath.4; + device and the device name in the examples must be + changed according to the configuration. A list of available wireless drivers and supported adapters can be - found in the &os; Hardware Notes. Copies of these notes - for various releases and architectures are available on + found in the &os; Hardware Notes, available on the Release - Information page of the &os; Web site. If a - native &os; driver for your wireless device does not - exist, it may be possible to directly use the &windows; - driver with the help of the - NDIS driver + Information page of the &os; website. If a + native &os; driver for the wireless device does not + exist, it may be possible to use the &windows; driver + with the help of the NDIS driver wrapper. - With that, you will need the modules that implement - cryptographic support for the security protocols you intend - to use. These are intended to be dynamically loaded on - demand by the &man.wlan.4; module but for now they must be - manually configured. The following modules are available: - &man.wlan.wep.4;, &man.wlan.ccmp.4; and &man.wlan.tkip.4;. - Both &man.wlan.ccmp.4; and &man.wlan.tkip.4; drivers are - only needed if you intend to use the WPA and/or 802.11i - security protocols. If your network does not use - encryption, you will not need &man.wlan.wep.4; support. To + In addition, the modules that implement cryptographic + support for the security protocols to use must be loaded. + These are intended to be dynamically loaded on demand by + the &man.wlan.4; module, but for now they must be manually + configured. The following modules are available: + &man.wlan.wep.4;, &man.wlan.ccmp.4;, and &man.wlan.tkip.4;. + The &man.wlan.ccmp.4; and &man.wlan.tkip.4; drivers are + only needed when using the WPA or + 802.11i security protocols. If the network does not use + encryption, &man.wlan.wep.4; support is not needed. To load these modules at boot time, add the following lines to /boot/loader.conf: wlan_wep_load="YES" wlan_ccmp_load="YES" wlan_tkip_load="YES" - With this information in the system bootstrap - configuration file (i.e., - /boot/loader.conf), you have to reboot - your &os; box. If you do not want to reboot your machine - for the moment, you can load the modules by hand using + Once this information has been added to + /boot/loader.conf, reboot the &os; + box. Alternately, load the modules by hand using &man.kldload.8;. - If you do not want to use modules, it is possible to - compile these drivers into the kernel by adding the - following lines to your kernel configuration file: + For users who do not want to use modules, it is + possible to compile these drivers into the kernel by + adding the following lines to a custom kernel + configuration file: device wlan # 802.11 support device wlan_wep # 802.11 WEP support device wlan_ccmp # 802.11 CCMP support device wlan_tkip # 802.11 TKIP support device wlan_amrr # AMRR transmit rate control algorithm device ath # Atheros pci/cardbus NIC's device ath_hal # pci/cardbus chip support options AH_SUPPORT_AR5416 # enable AR5416 tx/rx descriptors device ath_rate_sample # SampleRate tx rate control for ath With this information in the kernel configuration - file, recompile the kernel and reboot your &os; + file, recompile the kernel and reboot the &os; machine. - When the system is up, we could find some information - about the wireless device in the boot messages, like - this: + Information about the wireless device should appear + in the boot messages, like this: ath0: <Atheros 5212> mem 0x88000000-0x8800ffff irq 11 at device 0.0 on cardbus1 ath0: [ITHREAD] ath0: AR2413 mac 7.9 RF2413 phy 4.5 Infrastructure Mode - The infrastructure mode or BSS mode is the mode that is - typically used. In this mode, a number of wireless access - points are connected to a wired network. Each wireless - network has its own name, this name is called the SSID of the - network. Wireless clients connect to the wireless access - points. + Infrastructure (BSS) mode is the + mode that is typically used. In this mode, a number of + wireless access points are connected to a wired network. + Each wireless network has its own name, called the + SSID. Wireless clients connect to the + wireless access points. &os; Clients How to Find Access Points - To scan for networks, use the - ifconfig command. This request may - take a few moments to complete as it requires that the - system switches to each available wireless frequency and - probes for available access points. Only the super-user - can initiate such a scan: + To scan for available networks, use &man.ifconfig.8;. + This request may take a few moments to complete as it + requires the system to switch to each available wireless + frequency and probe for available access points. Only + the superuser can initiate a scan: &prompt.root; ifconfig wlan0 create wlandev ath0 &prompt.root; ifconfig wlan0 up scan SSID/MESH ID BSSID CHAN RATE S:N INT CAPS dlinkap 00:13:46:49:41:76 11 54M -90:96 100 EPS WPA WME freebsdap 00:11:95:c3:0d:ac 1 54M -83:96 100 EPS WPA - You must mark the interface - before you can scan. Subsequent scan requests do not - require you to mark the interface up again. + The interface must be before + it can scan. Subsequent scan requests do not require + the interface to be marked as up again. - The output of a scan request lists each BSS/IBSS - network found. Beside the name of the network, - SSID, we find the - BSSID which is the MAC address of the - access point. The CAPS field - identifies the type of each network and the capabilities - of the stations operating there: + The output of a scan request lists each + BSS/IBSS network + found. Besides listing the name of the network, the + SSID, the output also shows the + BSSID, which is the + MAC address of the access point. The + CAPS field identifies the type of + each network and the capabilities of the stations + operating there: Station Capability Codes Capability Code Meaning E - Extended Service Set (ESS). Indicates that + Extended Service Set + (ESS). Indicates that the station is part of an infrastructure network - (in contrast to an IBSS/ad-hoc network). + rather than an IBSS/ad-hoc + network. I - IBSS/ad-hoc network. Indicates that the - station is part of an ad-hoc network (in contrast - to an ESS network). + IBSS/ad-hoc network. + Indicates that the station is part of an ad-hoc + network rather than an ESS + network. P - Privacy. Data confidentiality is required - for all data frames exchanged within the BSS. - This means that this BSS requires the station to - use cryptographic means such as WEP, TKIP or - AES-CCMP to encrypt/decrypt data frames being - exchanged with others. + Privacy. Encryption is required for all + data frames exchanged within the + BSS using cryptographic means + such as WEP, + TKIP or + AES-CCMP. S Short Preamble. Indicates that the network - is using short preambles (defined in 802.11b High - Rate/DSSS PHY, short preamble utilizes a 56 bit - sync field in contrast to a 128 bit field used in - long preamble mode). + is using short preambles, defined in 802.11b High + Rate/DSSS PHY, and utilizes a 56 bit sync field + rather than the 128 bit field used in long + preamble mode. s Short slot time. Indicates that the 802.11g network is using a short slot time because there are no legacy (802.11b) stations present.
One can also display the current list of known networks with: &prompt.root; ifconfig wlan0 list scan This information may be updated automatically by the adapter or manually with a request. Old data is automatically removed from the cache, so over time this list may shrink unless more scans are done. Basic Settings This section provides a simple example of how to make the wireless network adapter work in &os; without - encryption. After you are familiar with these concepts, - we strongly recommend using - WPA to set up - your wireless network. + encryption. Once familiar with these concepts, it is + strongly recommend to use WPA to set up + the wireless network. There are three basic steps to configure a wireless - network: selecting an access point, authenticating your - station, and configuring an IP address. The following - sections discuss each step. + network: select an access point, authenticate the + station, and configure an IP address. + The following sections discuss each step. Selecting an Access Point - Most of time it is sufficient to let the system + Most of the time, it is sufficient to let the system choose an access point using the builtin heuristics. - This is the default behaviour when you mark an interface - up or otherwise configure an interface by listing it in - /etc/rc.conf, e.g.: + This is the default behaviour when an interface is + marked as up or it is listed in + /etc/rc.conf: wlans_ath0="wlan0" ifconfig_wlan0="DHCP" - If there are multiple access points and you want to - select a specific one, you can select it by its - SSID: + If there are multiple access points, a specific + one can be selected by its + SSID: wlans_ath0="wlan0" ifconfig_wlan0="ssid your_ssid_here DHCP" In an environment where there are multiple access - points with the same SSID (often done to simplify - roaming) it may be necessary to associate to one - specific device. In this case you can also specify the - BSSID of the access point (you can also leave off the - SSID): + points with the same SSID, which + is often done to simplify roaming, it may be necessary + to associate to one specific device. In this case, the + BSSID of the access point can be + specified, with or without the + SSID: wlans_ath0="wlan0" ifconfig_wlan0="ssid your_ssid_here bssid xx:xx:xx:xx:xx:xx DHCP" There are other ways to constrain the choice of an - access point such as limiting the set of frequencies the - system will scan on. This may be useful if you have a + access point, such as limiting the set of frequencies + the system will scan on. This may be useful for a multi-band wireless card as scanning all the possible channels can be time-consuming. To limit operation to a - specific band you can use the - parameter; e.g.: + specific band, use the + parameter: wlans_ath0="wlan0" ifconfig_wlan0="mode 11g ssid your_ssid_here DHCP" - will force the card to operate in 802.11g which is - defined only for 2.4GHz frequencies so any 5GHz channels - will not be considered. Other ways to do this are the - parameter, to lock operation to - one specific frequency, and the + This example will force the card to operate in + 802.11g, which is defined only for 2.4GHz frequencies + so any 5GHz channels will not be considered. This can + also be achieved with the + parameter, which locks + operation to one specific frequency, and the parameter, to specify a list of channels for scanning. More information about these - parameters can be found in the &man.ifconfig.8; manual - page. + parameters can be found in &man.ifconfig.8;. Authentication - Once you have selected an access point your station + Once an access point is selected, the station needs to authenticate before it can pass data. Authentication can happen in several ways. The most - common scheme used is termed open authentication and - allows any station to join the network and communicate. - This is the authentication you should use for test - purpose the first time you set up a wireless network. - Other schemes require cryptographic handshakes be - completed before data traffic can flow; either using - pre-shared keys or secrets, or more complex schemes that - involve backend services such as RADIUS. Most users - will use open authentication which is the default - setting. Next most common setup is WPA-PSK, also known - as WPA Personal, which is described below. + common scheme, open authentication, allows any station + to join the network and communicate. This is the + authentication to use for test purposes the first time + a wireless network is setup. Other schemes require + cryptographic handshakes to be completed before data + traffic can flow, either using pre-shared keys or + secrets, or more complex schemes that involve backend + services such as RADIUS. Open + authentication is the default setting. The next most + common setup is WPA-PSK, also + known as WPA Personal, which is + described in . - If you have an &apple; &airport; Extreme base - station for an access point you may need to configure - shared-key authentication together with a WEP key. - This can be done in the - /etc/rc.conf file or using the - &man.wpa.supplicant.8; program. If you have a single - &airport; base station you can setup access with - something like: + If using an &apple; &airport; Extreme base + station for an access point, shared-key authentication + together with a WEP key needs to + be configured. This can be configured in + /etc/rc.conf or by using + &man.wpa.supplicant.8;. For a single &airport; base + station, access can be configured with: wlans_ath0="wlan0" ifconfig_wlan0="authmode shared wepmode on weptxkey 1 wepkey 01234567 DHCP" - In general shared key authentication is to be - avoided because it uses the WEP key material in a - highly-constrained manner making it even easier to - crack the key. If WEP must be used (e.g., for - compatibility with legacy devices) it is better to use - WEP with open authentication. More - information regarding WEP can be found in the - . + In general, shared key authentication should be + avoided because it uses the WEP key + material in a highly-constrained manner, making it + even easier to crack the key. If + WEP must be used for compatibility + with legacy devices, it is better to use + WEP with open + authentication. More information regarding + WEP can be found in . - Getting an IP Address with DHCP - - Once you have selected an access point and set the - authentication parameters, you will have to get an IP - address to communicate. Most of time you will obtain - your wireless IP address via DHCP. To achieve that, - edit /etc/rc.conf and add - DHCP to the configuration for your - device as shown in various examples above: + Getting an <acronym>IP</acronym> Address with + <acronym>DHCP</acronym> + + Once an access point is selected and the + authentication parameters are set, an + IP address must be obtained in + order to communicate. Most of the time, the + IP address is obtained via + DHCP. To achieve that, edit + /etc/rc.conf and add + DHCP to the configuration for the + device: wlans_ath0="wlan0" ifconfig_wlan0="DHCP" - At this point, you are ready to bring up the - wireless interface: + The + wireless interface is now ready to bring up: &prompt.root; service netif start - Once the interface is running, use - ifconfig to see the status of the - interface ath0: + Once the interface is running, use &man.ifconfig.8; + to see the status of the interface + ath0: &prompt.root; ifconfig wlan0 wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 ether 00:11:95:d5:43:62 inet 192.168.1.100 netmask 0xffffff00 broadcast 192.168.1.255 media: IEEE 802.11 Wireless Ethernet OFDM/54Mbps mode 11g status: associated ssid dlinkap channel 11 (2462 Mhz 11g) bssid 00:13:46:49:41:76 country US ecm authmode OPEN privacy OFF txpower 21.5 bmiss 7 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS wme burst - The status: associated means you - are connected to the wireless network (to the - dlinkap network in our case). The - bssid 00:13:46:49:41:76 part is the - MAC address of your access point; the - authmode OPEN part informs you that - the communication is not encrypted. + The status: associated line means + that it is connected to the wireless network. The + bssid 00:13:46:49:41:76 is the + MAC address of the access point and + authmode OPEN indicates that the + communication is not encrypted. - Static IP Address + Static <acronym>IP</acronym> Address - In the case you cannot obtain an IP address from a - DHCP server, you can set a fixed IP address. Replace - the DHCP keyword shown above with the + In an IP address cannot be + obtained from a DHCP server, set a + fixed IP address. Replace the + DHCP keyword shown above with the address information. Be sure to retain any other - parameters you have set up for selecting an access - point: + parameters for selecting the access point: wlans_ath0="wlan0" ifconfig_wlan0="inet 192.168.1.100 netmask 255.255.255.0 ssid your_ssid_here" - WPA - - WPA (Wi-Fi Protected Access) is a security protocol - used together with 802.11 networks to address the lack of - proper authentication and the weakness of - WEP. WPA - leverages the 802.1X authentication protocol and uses one - of several ciphers instead of WEP for data integrity. The - only cipher required by WPA is TKIP (Temporary Key - Integrity Protocol). TKIP is a cipher that extends the - basic RC4 cipher used by WEP by adding integrity checking, - tamper detection, and measures for responding to any - detected intrusions. TKIP is designed to work on legacy - hardware with only software modification; it represents a - compromise that improves security but is still not - entirely immune to attack. WPA also specifies the - AES-CCMP cipher as an alternative to TKIP and that is - preferred when possible; for this specification the term - WPA2 (or RSN) is commonly used. - - WPA defines authentication and encryption protocols. - Authentication is most commonly done using one of two - techniques: by 802.1X and a backend authentication service - such as RADIUS, or by a minimal handshake between the - station and the access point using a pre-shared secret. - The former is commonly termed WPA Enterprise with the - latter known as WPA Personal. Since most people will not - set up a RADIUS backend server for their wireless network, - WPA-PSK is by far the most commonly encountered - configuration for WPA. - - The control of the wireless connection and the - authentication (key negotiation or authentication with a - server) is done with the &man.wpa.supplicant.8; utility. - This program requires a configuration file, + <acronym>WPA</acronym> + + Wi-Fi Protected Access (WPA) is a + security protocol used together with 802.11 networks to + address the lack of proper authentication and the weakness + of WEP. WPA leverages the 802.1X + authentication protocol and uses one of several ciphers + instead of WEP for data integrity. + The only cipher required by WPA is the + Temporary Key Integrity Protocol + (TKIP). TKIP is a + cipher that extends the basic RC4 cipher used by + WEP by adding integrity checking, + tamper detection, and measures for responding to detected + intrusions. TKIP is designed to work + on legacy hardware with only software modification. It + represents a compromise that improves security but is + still not entirely immune to attack. + WPA also specifies the + AES-CCMP cipher as an alternative to + TKIP, and that is preferred when + possible. For this specification, the term + WPA2 or RSN is + commonly used. + + WPA defines authentication and + encryption protocols. Authentication is most commonly + done using one of two techniques: by 802.1X and a backend + authentication service such as RADIUS, + or by a minimal handshake between the station and the + access point using a pre-shared secret. The former is + commonly termed WPA Enterprise and the + latter is known as WPA Personal. Since + most people will not set up a RADIUS + backend server for their wireless network, + WPA-PSK is by far the most commonly + encountered configuration for + WPA. + + The control of the wireless connection and the key + negotiation or authentication with a server is done using + &man.wpa.supplicant.8;. This program requires a + configuration file, /etc/wpa_supplicant.conf, to run. - More information regarding this file can be found in the - &man.wpa.supplicant.conf.5; manual page. + More information regarding this file can be found in + &man.wpa.supplicant.conf.5;. - WPA-PSK - - WPA-PSK, also known as WPA-Personal, is based on a - pre-shared key (PSK) generated from a given password and - that will be used as the master key in the wireless - network. This means every wireless user will share the - same key. WPA-PSK is intended for small networks where - the use of an authentication server is not possible or - desired. + <acronym>WPA-PSK</acronym> + + WPA-PSK, also known as + WPA Personal, is based on a + pre-shared key (PSK) which is + generated from a given password and used as the master + key in the wireless network. This means every wireless + user will share the same key. + WPA-PSK is intended for small + networks where the use of an authentication server is + not possible or desired. - Always use strong passwords that are - sufficiently long and made from a rich alphabet so - they will not be guessed and/or attacked. + Always use strong passwords that are sufficiently + long and made from a rich alphabet so that they will + not be easily guessed or attacked. - The first step is the configuration of the - /etc/wpa_supplicant.conf file with - the SSID and the pre-shared key of your network: + The first step is the configuration of + /etc/wpa_supplicant.conf with + the SSID and the pre-shared key of + the network: network={ ssid="freebsdap" psk="freebsdmall" } - Then, in /etc/rc.conf, we + Then, in /etc/rc.conf, indicate that the wireless device configuration will be - done with WPA and the IP address will be obtained with - DHCP: + done with WPA and the + IP address will be obtained with + DHCP: wlans_ath0="wlan0" ifconfig_wlan0="WPA DHCP" - Then we can bring up the interface: + Then, bring up the interface: &prompt.root; service netif start Starting wpa_supplicant. DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 5 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 6 DHCPOFFER from 192.168.0.1 DHCPREQUEST on wlan0 to 255.255.255.255 port 67 DHCPACK from 192.168.0.1 bound to 192.168.0.254 -- renewal in 300 seconds. wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 ether 00:11:95:d5:43:62 inet 192.168.0.254 netmask 0xffffff00 broadcast 192.168.0.255 media: IEEE 802.11 Wireless Ethernet OFDM/36Mbps mode 11g status: associated ssid freebsdap channel 1 (2412 Mhz 11g) bssid 00:11:95:c3:0d:ac country US ecm authmode WPA2/802.11i privacy ON deftxkey UNDEF AES-CCM 3:128-bit txpower 21.5 bmiss 7 scanvalid 450 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS wme burst roaming MANUAL - Or you can try to configure it manually using the - same /etc/wpa_supplicant.conf above, and - run: + Or, try to configure the interface manually using + the information in + /etc/wpa_supplicant.conf: &prompt.root; wpa_supplicant -i wlan0 -c /etc/wpa_supplicant.conf Trying to associate with 00:11:95:c3:0d:ac (SSID='freebsdap' freq=2412 MHz) Associated with 00:11:95:c3:0d:ac WPA: Key negotiation completed with 00:11:95:c3:0d:ac [PTK=CCMP GTK=CCMP] CTRL-EVENT-CONNECTED - Connection to 00:11:95:c3:0d:ac completed (auth) [id=0 id_str=] - The next operation is the launch of the - dhclient command to get the IP - address from the DHCP server: + The next operation is to launch &man.dhclient.8; + to get the IP address from the + DHCP server: &prompt.root; dhclient wlan0 DHCPREQUEST on wlan0 to 255.255.255.255 port 67 DHCPACK from 192.168.0.1 bound to 192.168.0.254 -- renewal in 300 seconds. &prompt.root; ifconfig wlan0 wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 ether 00:11:95:d5:43:62 inet 192.168.0.254 netmask 0xffffff00 broadcast 192.168.0.255 media: IEEE 802.11 Wireless Ethernet OFDM/36Mbps mode 11g status: associated ssid freebsdap channel 1 (2412 Mhz 11g) bssid 00:11:95:c3:0d:ac country US ecm authmode WPA2/802.11i privacy ON deftxkey UNDEF AES-CCM 3:128-bit txpower 21.5 bmiss 7 scanvalid 450 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS wme burst roaming MANUAL If /etc/rc.conf has an - ifconfig_wlan0 entry with the - DHCP string (like - ifconfig_wlan0="DHCP"), - dhclient will be launched - automatically after wpa_supplicant - associates with the access point. + ifconfig_wlan0="DHCP" entry, + &man.dhclient.8; will be launched automatically after + &man.wpa.supplicant.8; associates with the access + point. - If DHCP is not possible or desired, - you can set a static IP address after - wpa_supplicant has authenticated the + If DHCP is not possible or + desired, set a static IP address + after &man.wpa.supplicant.8; has authenticated the station: &prompt.root; ifconfig wlan0 inet 192.168.0.100 netmask 255.255.255.0 &prompt.root; ifconfig wlan0 wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 ether 00:11:95:d5:43:62 inet 192.168.0.100 netmask 0xffffff00 broadcast 192.168.0.255 media: IEEE 802.11 Wireless Ethernet OFDM/36Mbps mode 11g status: associated ssid freebsdap channel 1 (2412 Mhz 11g) bssid 00:11:95:c3:0d:ac country US ecm authmode WPA2/802.11i privacy ON deftxkey UNDEF AES-CCM 3:128-bit txpower 21.5 bmiss 7 scanvalid 450 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS wme burst roaming MANUAL - When DHCP is not used, you also have to manually set - the default gateway and the nameserver: + When DHCP is not used, the + default gateway and the nameserver also have to be + manually set: &prompt.root; route add default your_default_router &prompt.root; echo "nameserver your_DNS_server" >> /etc/resolv.conf - WPA with EAP-TLS - - The second way to use WPA is with an 802.1X backend - authentication server. In this case WPA is called - WPA-Enterprise to differentiate it from the less secure - WPA-Personal with its pre-shared key. - Authentication in WPA-Enterprise is based on the - Extensible Authentication Protocol (EAP). - - EAP does not come with an encryption method. - Instead, it was decided to embed EAP inside an encrypted - tunnel. There are many EAP authentication methods, but - EAP-TLS, EAP-TTLS, and EAP-PEAP are the most + <acronym>WPA</acronym> with + <acronym>EAP-TLS</acronym> + + The second way to use WPA is with + an 802.1X backend authentication server. In this case, + WPA is called + WPA Enterprise to differentiate it + from the less secure WPA Personal. + Authentication in WPA Enterprise is + based on the Extensible Authentication Protocol + (EAP). + + EAP does not come with an + encryption method. Instead, EAP is + embedded inside an encrypted tunnel. There are many + EAP authentication methods, but + EAP-TLS, EAP-TTLS, + and EAP-PEAP are the most common. - EAP-TLS (EAP with Transport Layer Security) is a - very well-supported authentication protocol in the - wireless world since it was the first EAP method to be - certified by the Wi-Fi alliance. - EAP-TLS will require three certificates to run: the CA - certificate (installed on all machines), the server - certificate for your authentication server, and one - client certificate for each wireless client. In this - EAP method, both authentication server and wireless - client authenticate each other in presenting their - respective certificates, and they verify that these - certificates were signed by your organization's - certificate authority (CA). + EAP with Transport Layer Security + (EAP-TLS) is a well-supported + wireless authentication protocol since it was the + first EAP method to be certified + by the Wi-Fi alliance. + EAP-TLS requires three certificates + to run: the certificate of the Certificate Authority + (CA) installed on all machines, the + server certificate for the authentication server, and + one client certificate for each wireless client. In + this EAP method, both the + authentication server and wireless client authenticate + each other by presenting their respective certificates, + and then verify that these certificates were signed by + the organization's CA. As previously, the configuration is done via /etc/wpa_supplicant.conf: network={ ssid="freebsdap" proto=RSN key_mgmt=WPA-EAP eap=TLS identity="loader" ca_cert="/etc/certs/cacert.pem" client_cert="/etc/certs/clientcert.pem" private_key="/etc/certs/clientkey.pem" private_key_passwd="freebsdmallclient" } This field indicates the network name - (SSID). + (SSID). - Here, we use RSN (&ieee; 802.11i) protocol, - i.e., WPA2. + This example uses the RSN + &ieee; 802.11i protocol, also known as + WPA2. The key_mgmt line refers to - the key management protocol we use. In our case it - is WPA using EAP authentication: - WPA-EAP. + the key management protocol to use. In this + example, it is WPA using + EAP authentication. - In this field, we mention the EAP method for our - connection. + This field indicates the EAP + method for the connection. The identity field contains - the identity string for EAP. + the identity string for + EAP. The ca_cert field indicates - the pathname of the CA certificate file. This file - is needed to verify the server certificate. + the pathname of the CA + certificate file. This file is needed to verify + the server certificate. The client_cert line gives the pathname to the client certificate file. This certificate is unique to each wireless client of the network. The private_key field is the pathname to the client certificate private key file. The private_key_passwd field contains the passphrase for the private key. - Then add the following lines to + Then, add the following lines to /etc/rc.conf: wlans_ath0="wlan0" ifconfig_wlan0="WPA DHCP" The next step is to bring up the interface: &prompt.root; service netif start Starting wpa_supplicant. DHCPREQUEST on wlan0 to 255.255.255.255 port 67 interval 7 DHCPREQUEST on wlan0 to 255.255.255.255 port 67 interval 15 DHCPACK from 192.168.0.20 bound to 192.168.0.254 -- renewal in 300 seconds. wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 ether 00:11:95:d5:43:62 inet 192.168.0.254 netmask 0xffffff00 broadcast 192.168.0.255 media: IEEE 802.11 Wireless Ethernet DS/11Mbps mode 11g status: associated ssid freebsdap channel 1 (2412 Mhz 11g) bssid 00:11:95:c3:0d:ac country US ecm authmode WPA2/802.11i privacy ON deftxkey UNDEF AES-CCM 3:128-bit txpower 21.5 bmiss 7 scanvalid 450 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS wme burst roaming MANUAL - As previously shown, it is also possible to bring up - the interface manually with both - wpa_supplicant and - ifconfig commands. + It is also possible to bring up the interface + manually using &man.wpa.supplicant.8; and + &man.ifconfig.8;. - WPA with EAP-TTLS - - With EAP-TLS both the authentication server and the - client need a certificate, with EAP-TTLS (EAP-Tunneled - Transport Layer Security) a client certificate is - optional. This method is close to what some secure web - sites do , where the web server can create a secure SSL - tunnel even if the visitors do not have client-side - certificates. EAP-TTLS will use the encrypted TLS - tunnel for safe transport of the authentication - data. - - The configuration is done via the - /etc/wpa_supplicant.conf - file: + <acronym>WPA</acronym> with + <acronym>EAP-TTLS</acronym> + + With EAP-TTLS, both the + authentication server and the client need a certificate. + With EAP-TTLS, a client certificate + is optional. This method is similar to a web server + which creates a secure SSL tunnel + even if visitors do not have client-side certificates. + EAP-TTLS uses an encrypted + TLS tunnel for safe transport of + the authentication data. + + The required configuration can be added to + /etc/wpa_supplicant.conf: network={ ssid="freebsdap" proto=RSN key_mgmt=WPA-EAP eap=TTLS identity="test" password="test" ca_cert="/etc/certs/cacert.pem" phase2="auth=MD5" } - In this field, we mention the EAP method for our - connection. + This field specifies the EAP + method for the connection. The identity field contains - the identity string for EAP authentication inside - the encrypted TLS tunnel. + the identity string for EAP + authentication inside the encrypted + TLS tunnel. The password field contains - the passphrase for the EAP authentication. + the passphrase for the EAP + authentication. The ca_cert field indicates - the pathname of the CA certificate file. This file - is needed to verify the server certificate. + the pathname of the CA + certificate file. This file is needed to verify + the server certificate. - In this field, we mention the authentication - method used in the encrypted TLS tunnel. In our - case, EAP with MD5-Challenge has been used. The - inner authentication phase is often - called phase2. + This field specifies the authentication + method used in the encrypted TLS + tunnel. In this example, + EAP with MD5-Challenge is used. + The inner authentication phase is + often called phase2. - You also have to add the following lines to + Next, add the following lines to /etc/rc.conf: wlans_ath0="wlan0" ifconfig_wlan0="WPA DHCP" The next step is to bring up the interface: &prompt.root; service netif start Starting wpa_supplicant. DHCPREQUEST on wlan0 to 255.255.255.255 port 67 interval 7 DHCPREQUEST on wlan0 to 255.255.255.255 port 67 interval 15 DHCPREQUEST on wlan0 to 255.255.255.255 port 67 interval 21 DHCPACK from 192.168.0.20 bound to 192.168.0.254 -- renewal in 300 seconds. wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 ether 00:11:95:d5:43:62 inet 192.168.0.254 netmask 0xffffff00 broadcast 192.168.0.255 media: IEEE 802.11 Wireless Ethernet DS/11Mbps mode 11g status: associated ssid freebsdap channel 1 (2412 Mhz 11g) bssid 00:11:95:c3:0d:ac country US ecm authmode WPA2/802.11i privacy ON deftxkey UNDEF AES-CCM 3:128-bit txpower 21.5 bmiss 7 scanvalid 450 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS wme burst roaming MANUAL - WPA with EAP-PEAP + <acronym>WPA</acronym> with + <acronym>EAP-PEAP</acronym> - PEAPv0/EAP-MSCHAPv2 is the most common PEAP - method. In the rest of this document, we will use the - PEAP term to refer to that method. + PEAPv0/EAP-MSCHAPv2 is the most + common PEAP method. In this + chapter, the term PEAP is used to + refer to that method. - PEAP (Protected EAP) has been designed as an - alternative to EAP-TTLS, and is the most used EAP - standard after EAP-TLS. In other words, if you have a - network with mixed OSes, PEAP should be the most - supported standard after EAP-TLS. + Protected EAP (PEAP) is designed + as an alternative to EAP-TTLS and + is the most used EAP standard after + EAP-TLS. In a network with mixed + operating systems, PEAP should be + the most supported standard after + EAP-TLS. - PEAP is similar to EAP-TTLS: it uses a server-side + PEAP is similar to + EAP-TTLS as it uses a server-side certificate to authenticate clients by creating an - encrypted TLS tunnel between the client and the - authentication server, which protects the ensuing - exchange of authentication information. In terms of - security, the difference between EAP-TTLS and PEAP is - that PEAP authentication broadcasts the username in the - clear, with only the password sent in the encrypted TLS - tunnel. EAP-TTLS will use the TLS tunnel for both - username and password. - - We have to edit the - /etc/wpa_supplicant.conf file and - add the EAP-PEAP related settings: + encrypted TLS tunnel between the + client and the authentication server, which protects + the ensuing exchange of authentication information. + PEAP authentication differs from + EAP-TTLS as it broadcasts the + username in the clear and only the password is sent + in the encrypted TLS tunnel. + EAP-TTLS will use the + TLS tunnel for both the username + and password. + + Add the following lines to + /etc/wpa_supplicant.conf to + configure the EAP-PEAP related + settings: network={ ssid="freebsdap" proto=RSN key_mgmt=WPA-EAP eap=PEAP identity="test" password="test" ca_cert="/etc/certs/cacert.pem" phase1="peaplabel=0" phase2="auth=MSCHAPV2" } - In this field, we mention the EAP method for our - connection. + This field specifies the EAP + method for the connection. The identity field contains - the identity string for EAP authentication inside - the encrypted TLS tunnel. + the identity string for EAP + authentication inside the encrypted + TLS tunnel. The password field contains - the passphrase for the EAP authentication. + the passphrase for the EAP + authentication. The ca_cert field indicates - the pathname of the CA certificate file. This file - is needed to verify the server certificate. + the pathname of the CA + certificate file. This file is needed to verify + the server certificate. This field contains the parameters for the - first phase of authentication (the TLS tunnel). - According to the authentication server used, you - will have to specify a specific label for - authentication. Most of the time, the label will be - client EAP encryption which is set by - using peaplabel=0. More - information can be found in the - &man.wpa.supplicant.conf.5; manual page. + first phase of authentication, the + TLS tunnel. According to the + authentication server used, specify a specific + label for authentication. Most of the time, the + label will be client EAP + encryption which is set by using + peaplabel=0. More information + can be found in &man.wpa.supplicant.conf.5;. - In this field, we mention the authentication - protocol used in the encrypted TLS tunnel. In the - case of PEAP, it is + This field specifies the authentication + protocol used in the encrypted + TLS tunnel. In the + case of PEAP, it is auth=MSCHAPV2. - The following must be added to + Add the following to /etc/rc.conf: wlans_ath0="wlan0" ifconfig_wlan0="WPA DHCP" - Then we can bring up the interface: + Then, bring up the interface: &prompt.root; service netif start Starting wpa_supplicant. DHCPREQUEST on wlan0 to 255.255.255.255 port 67 interval 7 DHCPREQUEST on wlan0 to 255.255.255.255 port 67 interval 15 DHCPREQUEST on wlan0 to 255.255.255.255 port 67 interval 21 DHCPACK from 192.168.0.20 bound to 192.168.0.254 -- renewal in 300 seconds. wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 ether 00:11:95:d5:43:62 inet 192.168.0.254 netmask 0xffffff00 broadcast 192.168.0.255 media: IEEE 802.11 Wireless Ethernet DS/11Mbps mode 11g status: associated ssid freebsdap channel 1 (2412 Mhz 11g) bssid 00:11:95:c3:0d:ac country US ecm authmode WPA2/802.11i privacy ON deftxkey UNDEF AES-CCM 3:128-bit txpower 21.5 bmiss 7 scanvalid 450 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS wme burst roaming MANUAL - WEP + <acronym>WEP</acronym> - WEP (Wired Equivalent Privacy) is part of the original - 802.11 standard. There is no authentication mechanism, - only a weak form of access control, and it is easily - cracked. + Wired Equivalent Privacy (WEP) is + part of the original 802.11 standard. There is no + authentication mechanism, only a weak form of access + control which is easily cracked. - WEP can be set up with - ifconfig: + WEP can be set up using + &man.ifconfig.8;: &prompt.root; ifconfig wlan0 create wlandev ath0 &prompt.root; ifconfig wlan0 inet 192.168.1.100 netmask 255.255.255.0 \ ssid my_net wepmode on weptxkey 3 wepkey 3:0x3456789012 - The weptxkey means which WEP - key will be used in the transmission. Here we used - the third key. This must match the setting in the - access point. If you do not have any idea of which - key is used by the access point, try - 1 (i.e., the first key) for this + The weptxkey specifies which + WEP key will be used in the + transmission. This example uses the third key. + This must match the setting on the access point. + When unsure which key is used by the access point, + try 1 (the first key) for this value. The wepkey selects one of the - WEP keys. It should be in the format - index:key. Key + WEP keys. It should be in the + format index:key. Key 1 is used by default; the index - only needs to be set if we use a key other - than the first key. + only needs to be set when using a key other than the + first key. - You must replace the - 0x3456789012 with the key - configured for use on the access point. + Replace the 0x3456789012 + with the key configured for use on the access + point. - You are encouraged to read the &man.ifconfig.8; manual - page for further information. + Refer to &man.ifconfig.8; for further + information. - The wpa_supplicant facility also - can be used to configure your wireless interface with WEP. - The example above can be set up by adding the following - lines to + The &man.wpa.supplicant.8; facility can be used to + configure a wireless interface with + WEP. The example above can be set up + by adding the following lines to /etc/wpa_supplicant.conf: network={ ssid="my_net" key_mgmt=NONE wep_key3=3456789012 wep_tx_keyidx=3 } Then: &prompt.root; wpa_supplicant -i wlan0 -c /etc/wpa_supplicant.conf Trying to associate with 00:13:46:49:41:76 (SSID='dlinkap' freq=2437 MHz) Associated with 00:13:46:49:41:76 Ad-hoc Mode - IBSS mode, also called ad-hoc mode, is designed for point - to point connections. For example, to establish an ad-hoc - network between the machine A and the machine - B, we will just need to choose two IP - addresses and a SSID. + IBSS mode, also called ad-hoc mode, is + designed for point to point connections. For example, to + establish an ad-hoc network between the machines + A and B, choose two + IP addresses and a + SSID. - On the box A: + On A: &prompt.root; ifconfig wlan0 create wlandev ath0 wlanmode adhoc &prompt.root; ifconfig wlan0 inet 192.168.0.1 netmask 255.255.255.0 ssid freebsdap &prompt.root; ifconfig wlan0 wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 ether 00:11:95:c3:0d:ac inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g <adhoc> status: running ssid freebsdap channel 2 (2417 Mhz 11g) bssid 02:11:95:c3:0d:ac country US ecm authmode OPEN privacy OFF txpower 21.5 scanvalid 60 protmode CTS wme burst - The adhoc parameter indicates the - interface is running in the IBSS mode. + The adhoc parameter indicates that the + interface is running in IBSS mode. - On B, we should be able to detect + B should now be able to detect A: &prompt.root; ifconfig wlan0 create wlandev ath0 wlanmode adhoc &prompt.root; ifconfig wlan0 up scan SSID/MESH ID BSSID CHAN RATE S:N INT CAPS freebsdap 02:11:95:c3:0d:ac 2 54M -64:-96 100 IS WME - The I in the output confirms the - machine A is in ad-hoc mode. We just have to - configure B with a different IP + The I in the output confirms that + A is in ad-hoc mode. Now, configure + B with a different IP address: &prompt.root; ifconfig wlan0 inet 192.168.0.2 netmask 255.255.255.0 ssid freebsdap &prompt.root; ifconfig wlan0 wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 ether 00:11:95:d5:43:62 inet 192.168.0.2 netmask 0xffffff00 broadcast 192.168.0.255 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g <adhoc> status: running ssid freebsdap channel 2 (2417 Mhz 11g) bssid 02:11:95:c3:0d:ac country US ecm authmode OPEN privacy OFF txpower 21.5 scanvalid 60 protmode CTS wme burst Both A and B are now ready to exchange information. &os; Host Access Points - &os; can act as an Access Point (AP) which eliminates the - need to buy a hardware AP or run an ad-hoc network. This can - be particularly useful when your &os; machine is acting as a - gateway to another network (e.g., the Internet). + &os; can act as an Access Point (AP) + which eliminates the need to buy a hardware + AP or run an ad-hoc network. This can + be particularly useful when a &os; machine is acting as a + gateway to another network such as the Internet. Basic Settings - Before configuring your &os; machine as an AP, the - kernel must be configured with the appropriate wireless - networking support for your wireless card. You also have to - add support for the security protocols you intend to - use. For more details, see - . + Before configuring a &os; machine as an + AP, the kernel must be configured with + the appropriate networking support for the wireless card + as well as the security protocols being used. For more + details, see . - The use of the NDIS driver wrapper and the &windows; - drivers do not currently allow AP operation. Only native - &os; wireless drivers support AP mode. + The NDIS driver wrapper for + &windows; drivers does not currently support + AP operation. Only native &os; + wireless drivers support AP + mode. - Once wireless networking support is loaded, you can - check if your wireless device supports the host-based access - point mode (also known as hostap mode): + Once wireless networking support is loaded, check if + the wireless device supports the host-based access point + mode, also known as hostap mode: &prompt.root; ifconfig wlan0 create wlandev ath0 &prompt.root; ifconfig wlan0 list caps drivercaps=6f85edc1<STA,FF,TURBOP,IBSS,HOSTAP,AHDEMO,TXPMGT,SHSLOT,SHPREAMBLE,MONITOR,MBSS,WPA1,WPA2,BURST,WME,WDS,BGSCAN,TXFRAG> cryptocaps=1f<WEP,TKIP,AES,AES_CCM,TKIPMIC> - This output displays the card capabilities; the - HOSTAP word confirms this wireless card - can act as an Access Point. Various supported ciphers are - also mentioned: WEP, TKIP, AES, etc. This information - is important to know what security protocols can be used - on the Access Point. + This output displays the card's capabilities. The + HOSTAP word confirms that this wireless + card can act as an AP. Various supported + ciphers are also listed: WEP, + TKIP, and AES. This + information indicates which security protocols can be used + on the AP. The wireless device can only be put into hostap mode during the creation of the network pseudo-device, so a previously created device must be destroyed first: &prompt.root; ifconfig wlan0 destroy then regenerated with the correct option before setting the other parameters: &prompt.root; ifconfig wlan0 create wlandev ath0 wlanmode hostap &prompt.root; ifconfig wlan0 inet 192.168.0.1 netmask 255.255.255.0 ssid freebsdap mode 11g channel 1 - Use ifconfig again to see the status - of the wlan0 interface: + Use &man.ifconfig.8; again to see the status of the + wlan0 interface: &prompt.root; ifconfig wlan0 wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 ether 00:11:95:c3:0d:ac inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g <hostap> status: running ssid freebsdap channel 1 (2412 Mhz 11g) bssid 00:11:95:c3:0d:ac country US ecm authmode OPEN privacy OFF txpower 21.5 scanvalid 60 protmode CTS wme burst dtimperiod 1 -dfs The hostap parameter indicates the interface is running in the host-based access point mode. The interface configuration can be done automatically at boot time by adding the following lines to /etc/rc.conf: wlans_ath0="wlan0" create_args_wlan0="wlanmode hostap" ifconfig_wlan0="inet 192.168.0.1 netmask 255.255.255.0 ssid freebsdap mode 11g channel 1" Host-based Access Point Without Authentication or Encryption - Although it is not recommended to run an AP without any - authentication or encryption, this is a simple way to check - if your AP is working. This configuration is also important - for debugging client issues. + Although it is not recommended to run an + AP without any authentication or + encryption, this is a simple way to check if the + AP is working. This configuration is + also important for debugging client issues. - Once the AP configured as previously shown, it is - possible from another wireless machine to initiate a scan to - find the AP: + Once the AP is configured, initiate + a scan from another wireless machine to find the + AP: &prompt.root; ifconfig wlan0 create wlandev ath0 &prompt.root; ifconfig wlan0 up scan SSID/MESH ID BSSID CHAN RATE S:N INT CAPS freebsdap 00:11:95:c3:0d:ac 1 54M -66:-96 100 ES WME - The client machine found the Access Point and can be - associated with it: + The client machine found the AP and + can be associated with it: &prompt.root; ifconfig wlan0 inet 192.168.0.2 netmask 255.255.255.0 ssid freebsdap &prompt.root; ifconfig wlan0 wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 ether 00:11:95:d5:43:62 inet 192.168.0.2 netmask 0xffffff00 broadcast 192.168.0.255 media: IEEE 802.11 Wireless Ethernet OFDM/54Mbps mode 11g status: associated ssid freebsdap channel 1 (2412 Mhz 11g) bssid 00:11:95:c3:0d:ac country US ecm authmode OPEN privacy OFF txpower 21.5 bmiss 7 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS wme burst - WPA Host-based Access Point - - This section will focus on setting up &os; Access Point - using the WPA security protocol. More details regarding WPA - and the configuration of WPA-based wireless clients can be - found in the . - - The hostapd daemon is used to - deal with client authentication and keys management on the - WPA enabled Access Point. - - In the following, all the configuration operations will - be performed on the &os; machine acting as AP. Once the - AP is correctly working, hostapd - should be automatically enabled at boot with the following - line in /etc/rc.conf: + <acronym>WPA</acronym> Host-based Access Point + + This section focuses on setting up a &os; + AP using the WPA + security protocol. More details regarding + WPA and the configuration of + WPA-based + wireless clients can be found in . + + The &man.hostapd.8; daemon is used to deal with client + authentication and key management on the + WPA-enabled AP. + + The following configuration operations are performed + on the &os; machine acting as the AP. + Once the AP is correctly working, + &man.hostapd.8; should be automatically enabled at boot + with the following line in + /etc/rc.conf: hostapd_enable="YES" - Before trying to configure - hostapd, be sure you have done - the basic settings introduced in the - . + Before trying to configure &man.hostapd.8;, first + configure the basic settings introduced in . - WPA-PSK + <acronym>WPA-PSK</acronym> - WPA-PSK is intended for small networks where the use - of an backend authentication server is not possible or - desired. + WPA-PSK is intended for small + networks where the use of a backend authentication server + is not possible or desired. - The configuration is done in the - /etc/hostapd.conf file: + The configuration is done in + /etc/hostapd.conf: interface=wlan0 debug=1 ctrl_interface=/var/run/hostapd ctrl_interface_group=wheel ssid=freebsdap wpa=1 wpa_passphrase=freebsdmall wpa_key_mgmt=WPA-PSK wpa_pairwise=CCMP TKIP This field indicates the wireless interface used - for the Access Point. + for the AP. This field sets the level of verbosity during the - execution of hostapd. A - value of 1 represents the minimal + execution of &man.hostapd.8;. A value of + 1 represents the minimal level. The ctrl_interface field gives - the pathname of the directory used by - hostapd to stores its - domain socket files for the communication with - external programs such as &man.hostapd.cli.8;. The - default value is used here. + the pathname of the directory used by &man.hostapd.8; + to store its domain socket files for the communication + with external programs such as &man.hostapd.cli.8;. + The default value is used in this example. The ctrl_interface_group line - sets the group (here, it is the - wheel group) allowed to access - to the control interface files. + sets the group which is allowed to access the control + interface files. This field sets the network name. - The wpa field enables WPA and - specifies which WPA authentication protocol will be - required. A value of 1 configures - the AP for WPA-PSK. + The wpa field enables + WPA and specifies which + WPA authentication protocol will + be required. A value of 1 + configures the AP for + WPA-PSK. The wpa_passphrase field - contains the ASCII passphrase for the WPA - authentication. + contains the ASCII passphrase for + WPA authentication. Always use strong passwords that are sufficiently long and made from a rich alphabet so - they will not be guessed and/or attacked. + that they will not be easily guessed or + attacked. - The wpa_key_mgmt line refers to - the key management protocol we use. In our case it is - WPA-PSK. + The wpa_key_mgmt line refers + to the key management protocol to use. This example + sets WPA-PSK. The wpa_pairwise field indicates the set of accepted encryption algorithms by - the Access Point. Here both TKIP (WPA) and CCMP - (WPA2) ciphers are accepted. CCMP cipher is an - alternative to TKIP and that is strongly preferred - when possible; TKIP should be used solely for stations - incapable of doing CCMP. + the AP. In this example, both + TKIP (WPA) and + CCMP (WPA2) + ciphers are accepted. The CCMP + cipher is an alternative to TKIP + and is strongly preferred when possible. + TKIP should be used solely for + stations incapable of doing + CCMP. - The next step is to start - hostapd: + The next step is to start &man.hostapd.8;: &prompt.root; service hostapd forcestart &prompt.root; ifconfig wlan0 wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 2290 inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 inet6 fe80::211:95ff:fec3:dac%ath0 prefixlen 64 scopeid 0x4 ether 00:11:95:c3:0d:ac media: IEEE 802.11 Wireless Ethernet autoselect mode 11g <hostap> status: associated ssid freebsdap channel 1 bssid 00:11:95:c3:0d:ac authmode WPA2/802.11i privacy MIXED deftxkey 2 TKIP 2:128-bit txpowmax 36 protmode CTS dtimperiod 1 bintval 100 - The Access Point is running, the clients can now be - associated with it, see - for more details. - It is possible to see the stations associated with the AP - using the ifconfig - wlan0 list sta - command. + Once the AP is running, the + clients can associate with it. See for more details. + It is possible to see the stations associated with the + AP using ifconfig + wlan0 list + sta. - WEP Host-based Access Point + <acronym>WEP</acronym> Host-based Access Point - It is not recommended to use WEP for setting up an - Access Point since there is no authentication mechanism and - it is easily to be cracked. Some legacy wireless cards only - support WEP as security protocol, these cards will only - allow to set up AP without authentication or encryption or - using the WEP protocol. + It is not recommended to use WEP for + setting up an AP since there is no + authentication mechanism and the encryption is easily + cracked. Some legacy wireless cards only support + WEP and these cards will only support + an AP without authentication or + encryption. The wireless device can now be put into hostap mode and - configured with the correct SSID and IP address: + configured with the correct SSID and + IP address: &prompt.root; ifconfig wlan0 create wlandev ath0 wlanmode hostap &prompt.root; ifconfig wlan0 inet 192.168.0.1 netmask 255.255.255.0 \ ssid freebsdap wepmode on weptxkey 3 wepkey 3:0x3456789012 mode 11g - The weptxkey means which WEP - key will be used in the transmission. Here we used the - third key (note that the key numbering starts with - 1). This parameter must be specified - to really encrypt the data. + The weptxkey indicates which + WEP key will be used in the + transmission. This example uses the third key as key + numbering starts with 1. This + parameter must be specified in order to encrypt the + data. - The wepkey means setting the - selected WEP key. It should in the format - index:key, if the index is - not given, key 1 is set. That is - to say we need to set the index if we use keys other - than the first key. + The wepkey sets the selected + WEP key. It should be in the format + index:key. If the index is + not given, key 1 is set. The index + needs to be set when using keys other than the first + key. - Use again ifconfig to see the status - of the wlan0 interface: + Use &man.ifconfig.8; to see the status of the + wlan0 interface: &prompt.root; ifconfig wlan0 wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 ether 00:11:95:c3:0d:ac inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g <hostap> status: running ssid freebsdap channel 4 (2427 Mhz 11g) bssid 00:11:95:c3:0d:ac country US ecm authmode OPEN privacy ON deftxkey 3 wepkey 3:40-bit txpower 21.5 scanvalid 60 protmode CTS wme burst dtimperiod 1 -dfs - From another wireless machine, it is possible to - initiate a scan to find the AP: + From another wireless machine, it is now possible to + initiate a scan to find the AP: &prompt.root; ifconfig wlan0 create wlandev ath0 &prompt.root; ifconfig wlan0 up scan SSID BSSID CHAN RATE S:N INT CAPS freebsdap 00:11:95:c3:0d:ac 1 54M 22:1 100 EPS - The client machine found the Access Point and can be - associated with it using the correct parameters (key, etc.), - see for more - details. + In this example, the client machine found the + AP and can associate with it using the + correct parameters. See for more details. - Using Both Wired and Wireless Connection + Using Both Wired and Wireless Connections - Wired connection provides better performance and - reliability, while wireless connection provides flexibility - and mobility, users of laptop computers usually want to - combine these together and roam seamlessly between the - two. + A wired connection provides better performance and + reliability, while a wireless connection provides flexibility + and mobility. Laptop users typically want to roam seamlessly + between the two types of connections. On &os;, it is possible to combine two or even more network interfaces together in a failover - fashion, that is, to use the most preferred and available - connection from a group of network interfaces, and have the - operating system switch automatically when the link state - changes. - - We will cover link aggregation and failover in - where an example for - using both wired and wireless connection is also provided at - . + fashion. This type of configuration uses the most preferred + and available connection from a group of network interfaces, + and the operating system switches automatically when the link + state changes. + + Link aggregation and failover is covered in and an example for using + both wired and wireless connections is provided at . Troubleshooting - If you are having trouble with wireless networking, there - are a number of steps you can take to help troubleshoot the - problem. + This section describes + a number of steps to help troubleshoot common wireless + networking problems. - If you do not see the access point listed when - scanning be sure you have not configured your wireless + If the access point is not listed when scanning, + check that the configuration has not limited the wireless device to a limited set of channels. - If you cannot associate to an access point verify the - configuration of your station matches the one of the + If the device cannot associate with an access point, + verify that the configuration matches the settings on the access point. This includes the authentication scheme and - any security protocols. Simplify your configuration as - much as possible. If you are using a security protocol - such as WPA or WEP configure the access point for open - authentication and no security to see if you can get - traffic to pass. + any security protocols. Simplify the configuration as + much as possible. If using a security protocol such as + WPA or WEP, + configure the access point for open authentication and + no security to see if traffic will pass. - Once you can associate to the access point diagnose - any security configuration using simple tools like + Once the system can associate with the access point, + diagnose the security configuration using tools like &man.ping.8;. - The wpa_supplicant has much - debugging support; try running it manually with the - option and look at the system - logs. + Debugging support is provided by + &man.wpa.supplicant.8;. Try running this utility manually + with the option and look at the + system logs. - There are also many lower-level debugging tools. You - can enable debugging messages in the 802.11 protocol - support layer using the wlandebug - program found in - /usr/src/tools/tools/net80211. - For example: + There are many lower-level debugging tools. + Debugging messages can be enabled in the 802.11 protocol + support layer using &man.wlandebug.8;. On a &os; system + prior to &os; 9.1, this program can be found in + /usr/src/tools/tools/net80211. + For example, to enable console messages related to + scanning for access points and the 802.11 protocol + handshakes required to arrange communication: &prompt.root; wlandebug -i ath0 +scan+auth+debug+assoc net.wlan.0.debug: 0 => 0xc80000<assoc,auth,scan> - can be used to enable console messages related to - scanning for access points and doing the 802.11 protocol - handshakes required to arrange communication. - - There are also many useful statistics maintained by - the 802.11 layer; the wlanstats tool + Many useful statistics are maintained by + the 802.11 layer and wlanstats, found + in /usr/src/tools/tools/net80211, will dump this information. These statistics should - identify all errors identified by the 802.11 layer. - Beware however that some errors are identified in the - device drivers that lie below the 802.11 layer so they may - not show up. To diagnose device-specific problems you - need to refer to the drivers' documentation. + display all errors identified by the 802.11 layer. + However, some errors are identified in the device drivers + that lie below the 802.11 layer so they may not show up. + To diagnose device-specific problems, refer to the + drivers' documentation. If the above information does not help to clarify the - problem, please submit a problem report and include output - from the above tools. + problem, submit a problem report and include output from the + above tools. Pav Lucistnik Written by
pav@FreeBSD.org
 Bluetooth Bluetooth Introduction Bluetooth is a wireless technology for creating personal networks operating in the 2.4 GHz unlicensed band, with a range of 10 meters. Networks are usually formed ad-hoc from portable devices such as cellular phones, handhelds and - laptops. Unlike the other popular wireless technology, Wi-Fi, - Bluetooth offers higher level service profiles, e.g., FTP-like - file servers, file pushing, voice transport, serial line - emulation, and more. + laptops. Unlike Wi-Fi wireless technology, Bluetooth offers + higher level service profiles, such as FTP-like file servers, + file pushing, voice transport, serial line emulation, and + more. The Bluetooth stack in &os; is implemented using the - Netgraph framework (see &man.netgraph.4;). A broad variety of - Bluetooth USB dongles is supported by the &man.ng.ubt.4; - driver. The Broadcom BCM2033 chip based Bluetooth devices are - supported via the &man.ubtbcmfw.4; and &man.ng.ubt.4; drivers. - The 3Com Bluetooth PC Card 3CRWB60-A is supported by the + &man.netgraph.4; framework. A broad variety of Bluetooth + USB dongles is supported by &man.ng.ubt.4;. + Broadcom BCM2033 based Bluetooth devices are supported by + the &man.ubtbcmfw.4; and &man.ng.ubt.4; drivers. The 3Com + Bluetooth PC Card 3CRWB60-A is supported by the &man.ng.bt3c.4; driver. Serial and UART based Bluetooth - devices are supported via &man.sio.4;, &man.ng.h4.4; and - &man.hcseriald.8;. This section describes the use of the USB - Bluetooth dongle. + devices are supported by &man.sio.4;, &man.ng.h4.4; and + &man.hcseriald.8;. This section describes the use of a + USB Bluetooth dongle. Plugging in the Device - By default Bluetooth device drivers are available as - kernel modules. Before attaching a device, you will need to - load the driver into the kernel: + By default, Bluetooth device drivers are available as + kernel modules. Before attaching a device, load the driver + into the kernel: &prompt.root; kldload ng_ubt If the Bluetooth device is present in the system during system startup, load the module from /boot/loader.conf: ng_ubt_load="YES" - Plug in your USB dongle. The output similar to the - following will appear on the console (or in syslog): + Plug in the USB dongle. Output + similar to the following will appear on the console and in + the system log: ubt0: vendor 0x0a12 product 0x0001, rev 1.10/5.25, addr 2 ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2 ubt0: Interface 1 (alt.config 5) endpoints: isoc-in=0x83, isoc-out=0x3, wMaxPacketSize=49, nframes=6, buffer size=294 - &man.service.8; - is used to start and stop the Bluetooth stack. It is a good - idea to stop the stack before unplugging the device, but it is - not (usually) fatal. When starting the stack, you will - receive output similar to the following: + To start and stop the Bluetooth stack, use + &man.service.8;. It is a good idea to stop the stack before + unplugging the device. When starting the stack, the output + should be similar to the following: &prompt.root; service bluetooth start ubt0 BD_ADDR: 00:02:72:00:d4:1a Features: 0xff 0xff 0xf 00 00 00 00 00 <3-Slot> <5-Slot> <Encryption> <Slot offset> <Timing accuracy> <Switch> <Hold mode> <Sniff mode> <Park mode> <RSSI> <Channel quality> <SCO link> <HV2 packets> <HV3 packets> <u-law log> <A-law log> <CVSD> <Paging scheme> <Power control> <Transparent SCO data> Max. ACL packet size: 192 bytes Number of ACL packets: 8 Max. SCO packet size: 64 bytes Number of SCO packets: 8 - Host Controller Interface (HCI) + Host Controller Interface + (<acronym>HCI</acronym>) HCI - Host Controller Interface (HCI) provides a command - interface to the baseband controller and link manager, and - access to hardware status and control registers. This - interface provides a uniform method of accessing the Bluetooth - baseband capabilities. HCI layer on the Host exchanges data - and commands with the HCI firmware on the Bluetooth hardware. - The Host Controller Transport Layer (i.e., physical bus) - driver provides both HCI layers with the ability to exchange - information with each other. - - A single Netgraph node of type hci is - created for a single Bluetooth device. The HCI node is - normally connected to the Bluetooth device driver node - (downstream) and the L2CAP node (upstream). All HCI - operations must be performed on the HCI node and not on the - device driver node. Default name for the HCI node is - devicehci. For more details refer to the - &man.ng.hci.4; manual page. + The Host Controller Interface (HCI) + provides a command interface to the baseband controller and + link manager as well as access to hardware status and control + registers. This interface provides a uniform method for + accessing Bluetooth baseband capabilities. The + HCI layer on the host exchanges data and + commands with the HCI firmware on the + Bluetooth hardware. The Host Controller Transport Layer + (physical bus) driver provides both HCI + layers with the ability to exchange information. + + A single netgraph node of type hci + is created for a single Bluetooth device. The + HCI node is normally connected to the + downstream Bluetooth device driver node and the upstream + L2CAP node. All HCI + operations must be performed on the HCI + node and not on the device driver node. The default name + for the HCI node is + devicehci. For more details, refer to + &man.ng.hci.4;. One of the most common tasks is discovery of Bluetooth - devices in RF proximity. This operation is called - inquiry. Inquiry and other HCI related - operations are done with the &man.hccontrol.8; utility. The - example below shows how to find out which Bluetooth devices - are in range. You should receive the list of devices in a few - seconds. Note that a remote device will only answer the - inquiry if it put into discoverable - mode. + devices in RF proximity. This operation is + called inquiry. Inquiry and other + HCI related operations are done using + &man.hccontrol.8;. The example below shows how to find out + which Bluetooth devices are in range. The list of devices + should be displayed in a few seconds. Note that a remote + device will only answer the inquiry if it is set to + discoverable mode. &prompt.user; hccontrol -n ubt0hci inquiry Inquiry result, num_responses=1 Inquiry result #0 BD_ADDR: 00:80:37:29:19:a4 Page Scan Rep. Mode: 0x1 Page Scan Period Mode: 00 Page Scan Mode: 00 Class: 52:02:04 Clock offset: 0x78ef Inquiry complete. Status: No error [00] - BD_ADDR is unique address of a - Bluetooth device, similar to MAC addresses of a network card. - This address is needed for further communication with a - device. It is possible to assign human readable name to a - BD_ADDR. The /etc/bluetooth/hosts file - contains information regarding the known Bluetooth hosts. The - following example shows how to obtain human readable name that + The BD_ADDR is the unique address of a + Bluetooth device, similar to the MAC + address of a network card. This address is needed for + further communication with a device. It is possible to + assign a human readable name to a BD_ADDR. Information + regarding the known Bluetooth hosts is contained in + /etc/bluetooth/hosts. The following + example shows how to obtain the human readable name that was assigned to the remote device: &prompt.user; hccontrol -n ubt0hci remote_name_request 00:80:37:29:19:a4 BD_ADDR: 00:80:37:29:19:a4 Name: Pav's T39 - If you perform an inquiry on a remote Bluetooth device, it - will find your computer as + If an inquiry is performed on a remote Bluetooth device, + it will find the computer as your.host.name (ubt0). The name assigned to the local device can be changed at any time. The Bluetooth system provides a point-to-point connection - (only two Bluetooth units involved), or a point-to-multipoint - connection. In the point-to-multipoint connection the - connection is shared among several Bluetooth devices. The - following example shows how to obtain the list of active + between two Bluetooth units, or a point-to-multipoint + connection which is shared among several Bluetooth devices. + The following example shows how to obtain the list of active baseband connections for the local device: &prompt.user; hccontrol -n ubt0hci read_connection_list Remote BD_ADDR Handle Type Mode Role Encrypt Pending Queue State 00:80:37:29:19:a4 41 ACL 0 MAST NONE 0 0 OPEN A connection handle is useful when - termination of the baseband connection is required. Note, - that it is normally not required to do it by hand. The stack + termination of the baseband connection is required, though + it is normally not required to do this by hand. The stack will automatically terminate inactive baseband connections. &prompt.root; hccontrol -n ubt0hci disconnect 41 Connection handle: 41 Reason: Connection terminated by local host [0x16] - Refer to hccontrol help for a complete - listing of available HCI commands. Most of the HCI commands - do not require superuser privileges. + Type hccontrol help for a complete + listing of available HCI commands. Most + of the HCI commands do not require + superuser privileges. Logical Link Control and Adaptation Protocol - (L2CAP) + (L2CAP) L2CAP - Logical Link Control and Adaptation Protocol (L2CAP) - provides connection-oriented and connectionless data services - to upper layer protocols with protocol multiplexing capability - and segmentation and reassembly operation. L2CAP permits + The Logical Link Control and Adaptation Protocol + (L2CAP) provides connection-oriented and + connectionless data services to upper layer protocols with + protocol multiplexing capability and segmentation and + reassembly operation. L2CAP permits higher level protocols and applications to transmit and - receive L2CAP data packets up to 64 kilobytes in - length. + receive L2CAP data packets up to 64 + kilobytes in length. - L2CAP is based around the concept of - channels. Channel is a logical - connection on top of baseband connection. Each channel is + L2CAP is based around the concept of + channels. A channel is a logical + connection on top of a baseband connection. Each channel is bound to a single protocol in a many-to-one fashion. Multiple channels can be bound to the same protocol, but a channel - cannot be bound to multiple protocols. Each L2CAP packet - received on a channel is directed to the appropriate higher - level protocol. Multiple channels can share the same baseband - connection. - - A single Netgraph node of type l2cap - is created for a single Bluetooth device. The L2CAP node is - normally connected to the Bluetooth HCI node (downstream) and - Bluetooth sockets nodes (upstream). Default name for the - L2CAP node is devicel2cap. For more details - refer to the &man.ng.l2cap.4; manual page. + cannot be bound to multiple protocols. Each + L2CAP packet received on a channel is + directed to the appropriate higher level protocol. Multiple + channels can share the same baseband connection. + + A single netgraph node of type l2cap + is created for a single Bluetooth device. The + L2CAP node is normally connected to the + downstream Bluetooth HCI node and upstream + Bluetooth socket nodes. The default name for the + L2CAP node is devicel2cap. + For more details refer to &man.ng.l2cap.4;. A useful command is &man.l2ping.8;, which can be used to ping other devices. Some Bluetooth implementations might not - return all of the data sent to them, so - 0 bytes in the following example is - normal. + return all of the data sent to them, so 0 + bytes in the following example is normal. &prompt.root; l2ping -a 00:80:37:29:19:a4 0 bytes from 0:80:37:29:19:a4 seq_no=0 time=48.633 ms result=0 0 bytes from 0:80:37:29:19:a4 seq_no=1 time=37.551 ms result=0 0 bytes from 0:80:37:29:19:a4 seq_no=2 time=28.324 ms result=0 0 bytes from 0:80:37:29:19:a4 seq_no=3 time=46.150 ms result=0 The &man.l2control.8; utility is used to perform various - operations on L2CAP nodes. This example shows how to obtain - the list of logical connections (channels) and the list of - baseband connections for the local device: + operations on L2CAP nodes. This example + shows how to obtain the list of logical connections (channels) + and the list of baseband connections for the local + device: &prompt.user; l2control -a 00:02:72:00:d4:1a read_channel_list L2CAP channels: Remote BD_ADDR SCID/ DCID PSM IMTU/ OMTU State 00:07:e0:00:0b:ca 66/ 64 3 132/ 672 OPEN &prompt.user; l2control -a 00:02:72:00:d4:1a read_connection_list L2CAP connections: Remote BD_ADDR Handle Flags Pending State 00:07:e0:00:0b:ca 41 O 0 OPEN - Another diagnostic tool is &man.btsockstat.1;. It does a - job similar to as &man.netstat.1; does, but for Bluetooth - network-related data structures. The example below shows the - same logical connection as &man.l2control.8; above. + Another diagnostic tool is &man.btsockstat.1;. It is + similar to &man.netstat.1;, but for Bluetooth network-related + data structures. The example below shows the same logical + connection as &man.l2control.8; above. &prompt.user; btsockstat Active L2CAP sockets PCB Recv-Q Send-Q Local address/PSM Foreign address CID State c2afe900 0 0 00:02:72:00:d4:1a/3 00:07:e0:00:0b:ca 66 OPEN Active RFCOMM sessions L2PCB PCB Flag MTU Out-Q DLCs State c2afe900 c2b53380 1 127 0 Yes OPEN Active RFCOMM sockets PCB Recv-Q Send-Q Local address Foreign address Chan DLCI State c2e8bc80 0 250 00:02:72:00:d4:1a 00:07:e0:00:0b:ca 3 6 OPEN - RFCOMM Protocol + <acronym>RFCOMM</acronym> Protocol - The RFCOMM protocol provides emulation of serial ports - over the L2CAP protocol. The protocol is based on the ETSI - standard TS 07.10. RFCOMM is a simple transport protocol, + The RFCOMM protocol provides emulation + of serial ports over the L2CAP protocol. + The protocol is based on the ETSI standard TS 07.10. + RFCOMM is a simple transport protocol, with additional provisions for emulating the 9 circuits of - RS-232 (EIATIA-232-E) serial ports. The RFCOMM protocol - supports up to 60 simultaneous connections (RFCOMM channels) - between two Bluetooth devices. - - For the purposes of RFCOMM, a complete communication path - involves two applications running on different devices (the - communication endpoints) with a communication segment between - them. RFCOMM is intended to cover applications that make use - of the serial ports of the devices in which they reside. The - communication segment is a Bluetooth link from one device to - another (direct connect). - - RFCOMM is only concerned with the connection between the - devices in the direct connect case, or between the device and - a modem in the network case. RFCOMM can support other - configurations, such as modules that communicate via Bluetooth - wireless technology on one side and provide a wired interface - on the other side. - - In &os; the RFCOMM protocol is implemented at the + RS-232 (EIATIA-232-E) serial ports. RFCOMM + supports up to 60 simultaneous connections + (RFCOMM channels) between two Bluetooth + devices. + + For the purposes of RFCOMM, a complete + communication path involves two applications running on the + communication endpoints with a communication segment between + them. RFCOMM is intended to cover + applications that make use of the serial ports of the devices + in which they reside. The communication segment is a direct + connect Bluetooth link from one device to another. + + RFCOMM is only concerned with the + connection between the devices in the direct connect case, + or between the device and a modem in the network case. + RFCOMM can support other configurations, + such as modules that communicate via Bluetooth wireless + technology on one side and provide a wired interface on the + other side. + + In &os;, RFCOMM is implemented at the Bluetooth sockets layer. Pairing of Devices By default, Bluetooth communication is not authenticated, and any device can talk to any other device. A Bluetooth - device (for example, cellular phone) may choose to require - authentication to provide a particular service (for example, - Dial-Up service). Bluetooth authentication is normally done - with PIN codes. A PIN code is an ASCII - string up to 16 characters in length. User is required to - enter the same PIN code on both devices. Once user has - entered the PIN code, both devices will generate a - link key. After that the link key can be - stored either in the devices themselves or in a persistent - storage. Next time both devices will use previously generated - link key. The described above procedure is called - pairing. Note that if the link key is - lost by any device then pairing must be repeated. - - The &man.hcsecd.8; daemon is responsible for handling of - all Bluetooth authentication requests. The default - configuration file is - /etc/bluetooth/hcsecd.conf. An example - section for a cellular phone with the PIN code arbitrarily set - to 1234 is shown below: + device, such as a cellular phone, may choose to require + authentication to provide a particular service. Bluetooth + authentication is normally done with a + PIN code, an ASCII + string up to 16 characters in length. The user is required + to enter the same PIN code on both devices. + Once the user has entered the PIN code, + both devices will generate a link key. + After that, the link key can be stored either in the devices + or in a persistent storage. Next time, both devices will + use the previously generated link key. This procedure is + called pairing. Note that if the link + key is lost by either device, the pairing must be + repeated. + + The &man.hcsecd.8; daemon is responsible for handling + Bluetooth authentication requests. The default configuration + file is /etc/bluetooth/hcsecd.conf. An + example section for a cellular phone with the + PIN code arbitrarily set to + 1234 is shown below: device { bdaddr 00:80:37:29:19:a4; name "Pav's T39"; key nokey; pin "1234"; } - There is no limitation on PIN codes (except length). Some - devices (for example Bluetooth headsets) may have a fixed PIN - code built in. The switch forces the - &man.hcsecd.8; daemon to stay in the foreground, so it is easy - to see what is happening. Set the remote device to receive - pairing and initiate the Bluetooth connection to the remote - device. The remote device should say that pairing was - accepted, and request the PIN code. Enter the same PIN code - as you have in hcsecd.conf. Now your PC - and the remote device are paired. Alternatively, you can - initiate pairing on the remote device. - - The following line can be added to the - /etc/rc.conf file to have - hcsecd started automatically on - system start: + The only limitation on PIN codes is + length. Some devices, such as Bluetooth headsets, may have + a fixed PIN code built in. The + switch forces &man.hcsecd.8; to stay in + the foreground, so it is easy to see what is happening. Set + the remote device to receive pairing and initiate the + Bluetooth connection to the remote device. The remote device + should indicate that pairing was accepted and request the + PIN code. Enter the same + PIN code listed in + hcsecd.conf. Now the computer and the + remote device are paired. Alternatively, pairing can be + initiated on the remote device. + + The following line can be added to + /etc/rc.conf to configure &man.hcsecd.8; + to start automatically on system start: hcsecd_enable="YES" - The following is a sample of the - hcsecd daemon output: + The following is a sample of the &man.hcsecd.8; daemon + output: hcsecd[16484]: Got Link_Key_Request event from 'ubt0hci', remote bdaddr 0:80:37:29:19:a4 hcsecd[16484]: Found matching entry, remote bdaddr 0:80:37:29:19:a4, name 'Pav's T39', link key doesn't exist hcsecd[16484]: Sending Link_Key_Negative_Reply to 'ubt0hci' for remote bdaddr 0:80:37:29:19:a4 hcsecd[16484]: Got PIN_Code_Request event from 'ubt0hci', remote bdaddr 0:80:37:29:19:a4 hcsecd[16484]: Found matching entry, remote bdaddr 0:80:37:29:19:a4, name 'Pav's T39', PIN code exists hcsecd[16484]: Sending PIN_Code_Reply to 'ubt0hci' for remote bdaddr 0:80:37:29:19:a4 - Service Discovery Protocol (SDP) + Service Discovery Protocol + (<acronym>SDP</acronym>) SDP - The Service Discovery Protocol (SDP) provides the means - for client applications to discover the existence of services - provided by server applications as well as the attributes of - those services. The attributes of a service include the type - or class of service offered and the mechanism or protocol - information needed to utilize the service. + The Service Discovery Protocol (SDP) + provides the means for client applications to discover the + existence of services provided by server applications as well + as the attributes of those services. The attributes of a + service include the type or class of service offered and the + mechanism or protocol information needed to utilize the + service. - SDP involves communication between a SDP server and a SDP + SDP involves communication between a + SDP server and a SDP client. The server maintains a list of service records that describe the characteristics of services associated with the server. Each service record contains information about a single service. A client may retrieve information from a - service record maintained by the SDP server by issuing a SDP - request. If the client, or an application associated with the - client, decides to use a service, it must open a separate - connection to the service provider in order to utilize the - service. SDP provides a mechanism for discovering services - and their attributes, but it does not provide a mechanism for - utilizing those services. - - Normally, a SDP client searches for services based on some - desired characteristics of the services. However, there are - times when it is desirable to discover which types of services - are described by an SDP server's service records without any a - priori information about the services. This process of + service record maintained by the SDP server + by issuing a SDP request. If the client, + or an application associated with the client, decides to use + a service, it must open a separate connection to the service + provider in order to utilize the service. + SDP provides a mechanism for discovering + services and their attributes, but it does not provide a + mechanism for utilizing those services. + + Normally, a SDP client searches for + services based on some desired characteristics of the + services. However, there are times when it is desirable to + discover which types of services are described by an + SDP server's service records without any + prior information about the services. This process of looking for any offered services is called browsing. - The Bluetooth SDP server &man.sdpd.8; and command line - client &man.sdpcontrol.8; are included in the standard &os; - installation. The following example shows how to perform a - SDP browse query. + The Bluetooth SDP server, &man.sdpd.8;, + and command line client, &man.sdpcontrol.8;, are included in + the standard &os; installation. The following example shows + how to perform a SDP browse query. &prompt.user; sdpcontrol -a 00:01:03:fc:6e:ec browse Record Handle: 00000000 Service Class ID List: Service Discovery Server (0x1000) Protocol Descriptor List: L2CAP (0x0100) Protocol specific parameter #1: u/int/uuid16 1 Protocol specific parameter #2: u/int/uuid16 1 Record Handle: 0x00000001 Service Class ID List: Browse Group Descriptor (0x1001) Record Handle: 0x00000002 Service Class ID List: LAN Access Using PPP (0x1102) Protocol Descriptor List: L2CAP (0x0100) RFCOMM (0x0003) Protocol specific parameter #1: u/int8/bool 1 Bluetooth Profile Descriptor List: LAN Access Using PPP (0x1102) ver. 1.0 - ... and so on. Note that each service has a list of - attributes (RFCOMM channel for example). Depending on the - service you might need to make a note of some of the + Note that each service has a list of attributes, such + as the RFCOMM channel. Depending on the + service, the user might need to make note of some of the attributes. Some Bluetooth implementations do not support - service browsing and may return an empty list. In this case + service browsing and may return an empty list. In this case, it is possible to search for the specific service. The - example below shows how to search for the OBEX Object Push - (OPUSH) service: + example below shows how to search for the + OBEX Object Push + (OPUSH) service: &prompt.user; sdpcontrol -a 00:01:03:fc:6e:ec search OPUSH Offering services on &os; to Bluetooth clients is done with the &man.sdpd.8; server. The following line can be added - to the /etc/rc.conf file: + to /etc/rc.conf: sdpd_enable="YES" - Then the sdpd daemon can be + Then the &man.sdpd.8; daemon can be started with: &prompt.root; service sdpd start The local server application that wants to provide Bluetooth service to the remote clients will register service - with the local SDP daemon. The example of such application is - &man.rfcomm.pppd.8;. Once started it will register Bluetooth - LAN service with the local SDP daemon. - - The list of services registered with the local SDP server - can be obtained by issuing SDP browse query via local control + with the local SDP daemon. An example of + such an application is &man.rfcomm.pppd.8;. Once started, + it will register the Bluetooth LAN service with the local + SDP daemon. + + The list of services registered with the local + SDP server can be obtained by issuing a + SDP browse query via the local control channel: &prompt.root; sdpcontrol -l browse - Dial-Up Networking (DUN) and Network Access with PPP - (LAN) Profiles + Dial-Up Networking and Network Access with + <acronym>PPP</acronym> Profiles - The Dial-Up Networking (DUN) profile is mostly used with - modems and cellular phones. The scenarios covered by this - profile are the following: + The Dial-Up Networking (DUN) profile is + mostly used with modems and cellular phones. The scenarios + covered by this profile are the following: - use of a cellular phone or modem by a computer as a + Use of a cellular phone or modem by a computer as a wireless modem for connecting to a dial-up Internet access - server, or using other dial-up services; + server, or for using other dial-up services. - use of a cellular phone or modem by a computer to + Use of a cellular phone or modem by a computer to receive data calls. - Network Access with PPP (LAN) profile can be used in the - following situations: + Network access with a PPP profile can + be used in the following situations: - LAN access for a single Bluetooth device; + LAN access for a single Bluetooth + device. - LAN access for multiple Bluetooth devices; + LAN access for multiple Bluetooth + devices. - PC to PC (using PPP networking over serial cable - emulation). + PC to PC connection using PPP + networking over serial cable emulation. - In &os; both profiles are implemented with &man.ppp.8; and - &man.rfcomm.pppd.8; - a wrapper that converts RFCOMM Bluetooth - connection into something PPP can operate with. Before any - profile can be used, a new PPP label in the - /etc/ppp/ppp.conf must be created. - Consult &man.rfcomm.pppd.8; manual page for examples. - - In the following example &man.rfcomm.pppd.8; will be used - to open RFCOMM connection to remote device with BD_ADDR - 00:80:37:29:19:a4 on DUN RFCOMM channel. The actual RFCOMM - channel number will be obtained from the remote device via - SDP. It is possible to specify RFCOMM channel by hand, and in - this case &man.rfcomm.pppd.8; will not perform SDP query. Use - &man.sdpcontrol.8; to find out RFCOMM channel on the remote - device. + In &os;, these profiles are implemented with &man.ppp.8; + and the &man.rfcomm.pppd.8; wrapper which converts a + RFCOMM Bluetooth connection into something + PPP can use. Before a profile can be used, + a new PPP label must be created in + /etc/ppp/ppp.conf. Consult + &man.rfcomm.pppd.8; for examples. + + In the following example, &man.rfcomm.pppd.8; is used + to open a RFCOMM connection to a remote + device with a BD_ADDR of 00:80:37:29:19:a4 + on a DUN RFCOMM channel. + The actual RFCOMM channel number will be + obtained from the remote device via SDP. + It is possible to specify the RFCOMM + channel by hand, and in this case &man.rfcomm.pppd.8; will + not perform the SDP query. Use + &man.sdpcontrol.8; to find out the RFCOMM + channel on the remote device. &prompt.root; rfcomm_pppd -a 00:80:37:29:19:a4 -c -C dun -l rfcomm-dialup - In order to provide Network Access with PPP (LAN) service - the &man.sdpd.8; server must be running. A new entry for LAN - clients must be created in the - /etc/ppp/ppp.conf file. Consult - &man.rfcomm.pppd.8; manual page for examples. Finally, start - RFCOMM PPP server on valid RFCOMM channel number. The RFCOMM - PPP server will automatically register Bluetooth LAN service - with the local SDP daemon. The example below shows how to - start RFCOMM PPP server. + In order to provide network access with the + PPP LAN service, + &man.sdpd.8; must be running and a new entry for + LAN clients must be created in + /etc/ppp/ppp.conf. Consult + &man.rfcomm.pppd.8; for examples. Finally, start the + RFCOMM PPP server on a + valid RFCOMM channel number. The + RFCOMM PPP server will + automatically register the Bluetooth LAN + service with the local SDP daemon. The + example below shows how to start the RFCOMM + PPP server. &prompt.root; rfcomm_pppd -s -C 7 -l rfcomm-server - OBEX Object Push (OPUSH) Profile + <acronym>OBEX</acronym> Object Push + (<acronym>OPUSH</acronym>) Profile OBEX - OBEX is a widely used protocol for simple file transfers - between mobile devices. Its main use is in infrared - communication, where it is used for generic file transfers - between notebooks or PDAs, and for sending business cards or - calendar entries between cellular phones and other devices - with PIM applications. - - The OBEX server and client are implemented as a - third-party package obexapp, which - is available as comms/obexapp port. - - OBEX client is used to push and/or pull objects from the - OBEX server. An object can, for example, be a business card - or an appointment. The OBEX client can obtain RFCOMM channel - number from the remote device via SDP. This can be done by - specifying service name instead of RFCOMM channel number. - Supported service names are: IrMC, FTRN and OPUSH. It is - possible to specify RFCOMM channel as a number. Below is an - example of an OBEX session, where device information object is - pulled from the cellular phone, and a new object (business - card) is pushed into the phone's directory. + OBEX is a widely used protocol for + simple file transfers between mobile devices. Its main use + is in infrared communication, where it is used for generic + file transfers between notebooks or PDAs, + and for sending business cards or calendar entries between + cellular phones and other devices with PIM + applications. + + The OBEX server and client are + implemented as a third-party package, + obexapp, which is available as + comms/obexapp package or + port. + + The OBEX client is used to push and/or + pull objects from the OBEX server. An + object can, for example, be a business card or an appointment. + The OBEX client can obtain the + RFCOMM channel number from the remote + device via SDP. This can be done by + specifying the service name instead of the + RFCOMM channel number. Supported service + names are: IrMC, FTRN, + and OPUSH. It is also possible to specify + the RFCOMM channel as a number. Below is + an example of an OBEX session where the + device information object is pulled from the cellular phone, + and a new object, the business card, is pushed into the + phone's directory. &prompt.user; obexapp -a 00:80:37:29:19:a4 -C IrMC obex> get telecom/devinfo.txt devinfo-t39.txt Success, response: OK, Success (0x20) obex> put new.vcf Success, response: OK, Success (0x20) obex> di Success, response: OK, Success (0x20) - In order to provide OBEX Object Push service, &man.sdpd.8; - server must be running. A root folder, where all incoming - objects will be stored, must be created. The default path to - the root folder - is /var/spool/obex. - Finally, start OBEX server on valid RFCOMM channel number. - The OBEX server will automatically register OBEX Object Push - service with the local SDP daemon. The example below shows - how to start OBEX server. + In order to provide the OPUSH service, + &man.sdpd.8; must be running and a root folder, where all + incoming objects will be stored, must be created. The + default path to the root folder is /var/spool/obex. Finally, + start the OBEX server on a valid + RFCOMM channel number. The + OBEX server will automatically register + the OPUSH service with the local + SDP daemon. The example below shows how + to start the OBEX server. &prompt.root; obexapp -s -C 10 - Serial Port Profile (SPP) - - The Serial Port Profile (SPP) allows Bluetooth devices to - perform RS232 (or similar) serial cable emulation. The - scenario covered by this profile deals with legacy - applications using Bluetooth as a cable replacement, through a - virtual serial port abstraction. - - The &man.rfcomm.sppd.1; utility implements the Serial Port - profile. A pseudo tty is used as a virtual serial port - abstraction. The example below shows how to connect to a - remote device Serial Port service. Note that you do not have - to specify a RFCOMM channel - &man.rfcomm.sppd.1; can obtain - it from the remote device via SDP. If you would like to - override this, specify a RFCOMM channel on the command + Serial Port Profile + + The Serial Port Profile (SPP) allows + Bluetooth devices to perform serial cable emulation. This + profile allows legacy applications to use Bluetooth as a + cable replacement, through a virtual serial port + abstraction. + + In &os;, &man.rfcomm.sppd.1; implements + SPP and a pseudo tty is used as a virtual + serial port abstraction. The example below shows how to + connect to a remote device serial port service. A + RFCOMM channel does not have to be + specified as &man.rfcomm.sppd.1; can obtain it from the + remote device via SDP. To override this, + specify a RFCOMM channel on the command line. &prompt.root; rfcomm_sppd -a 00:07:E0:00:0B:CA -t /dev/ttyp6 rfcomm_sppd[94692]: Starting on /dev/ttyp6... Once connected, the pseudo tty can be used as serial port: &prompt.root; cu -l ttyp6 Troubleshooting A Remote Device Cannot Connect Some older Bluetooth devices do not support role switching. By default, when &os; is accepting a new connection, it tries to perform a role switch and become master. Devices, which do not support this will not be able - to connect. Note that role switching is performed when a - new connection is being established, so it is not possible - to ask the remote device if it does support role switching. - There is a HCI option to disable role switching on the local - side: + to connect. Since role switching is performed when a + new connection is being established, it is not possible + to ask the remote device if it supports role switching. + There is a HCI option to disable role + switching on the local side: &prompt.root; hccontrol -n ubt0hci write_node_role_switch 0 - Something is Going Wrong, Can I See What Exactly is - Happening? - - Yes, you can. Use the third-party package - hcidump, which is available as - comms/hcidump port. The - hcidump utility is similar to - &man.tcpdump.1;. It can be used to display the content of - the Bluetooth packets on the terminal and to dump the - Bluetooth packets to a file. + Displaying Bluetooth Packets + + Use the third-party package + hcidump, which is available as a + comms/hcidump package or + port. This utility is similar to &man.tcpdump.1; and can + be used to display the contents of Bluetooth packets on + the terminal and to dump the Bluetooth packets to a + file. Andrew Thompson Written by Bridging Introduction - IP subnet + IP + subnet bridge - It is sometimes useful to divide one physical network - (such as an Ethernet segment) into two separate network - segments without having to create IP subnets and use a router - to connect the segments together. A device that connects two - networks together in this fashion is called a - bridge. A FreeBSD system with two network - interface cards can act as a bridge. - - The bridge works by learning the MAC layer addresses - (Ethernet addresses) of the devices on each of its network - interfaces. It forwards traffic between two networks only - when its source and destination are on different + It is sometimes useful to divide one physical network, + such as an Ethernet segment, into two separate network + segments without having to create IP + subnets and use a router to connect the segments together. + A device that connects two networks together in this fashion + is called a bridge. A &os; system with two + network interface cards can act as a bridge. + + The bridge works by learning the MAC + layer (Ethernet) addresses of the devices on each of its + network interfaces. It forwards traffic between two networks + only when the source and destination are on different networks. In many respects, a bridge is like an Ethernet switch with very few ports. Situations Where Bridging Is Appropriate There are many common situations in which a bridge is used today. Connecting Networks The basic operation of a bridge is to join two or more network segments together. There are many reasons to use a host based bridge over plain networking equipment such as - cabling constraints, firewalling or connecting pseudo - networks such as a Virtual Machine interface. A bridge can + cabling constraints, firewalling, or connecting pseudo + networks such as a virtual machine interface. A bridge can also connect a wireless interface running in hostap mode to a wired network and act as an access point. Filtering/Traffic Shaping Firewall firewall NAT A common situation is where firewall functionality is - needed without routing or network address translation - (NAT). + needed without routing or Network Address Translation + (NAT). - An example is a small company that is connected via DSL - or ISDN to their ISP. They have a 13 globally-accessible IP - addresses from their ISP and have 10 PCs on their network. - In this situation, using a router-based firewall is - difficult because of subnetting issues. + An example is a small company that is connected via + DSL + or ISDN to an ISP. + There are thirteen globally-accessible IP + addresses from the ISP and ten computers + on the network. In this situation, using a router-based + firewall is difficult because of subnetting issues. router - DSL - ISDN + DSL + ISDN A bridge-based firewall can be configured and dropped - into the path just downstream of their DSL/ISDN router - without any IP numbering issues. + into the path just downstream of the DSL + or ISDN router without any + IP numbering issues. Network Tap A bridge can join two network segments and be used to - inspect all Ethernet frames that pass between them. This - can either be from using &man.bpf.4;/&man.tcpdump.1; on the - bridge interface or by sending a copy of all frames out an - additional interface (span port). + inspect all Ethernet frames that pass between them using + &man.bpf.4; and &man.tcpdump.1; on the bridge interface or + by sending a copy of all frames out an additional interface + known as a span port. - Layer 2 VPN + Layer 2 <acronym>VPN</acronym> - Two Ethernet networks can be joined across an IP link by - bridging the networks to an EtherIP tunnel or a &man.tap.4; - based solution such as OpenVPN. + Two Ethernet networks can be joined across an + IP link by bridging the networks to an + EtherIP tunnel or a &man.tap.4; based solution such as + OpenVPN. Layer 2 Redundancy A network can be connected together with multiple links - and use the Spanning Tree Protocol to block redundant paths. - For an Ethernet network to function properly only one active - path can exist between two devices, Spanning Tree will - detect loops and put the redundant links into a blocked - state. Should one of the active links fail then the - protocol will calculate a different tree and reenable one of - the blocked paths to restore connectivity to all points in - the network. + and use the Spanning Tree Protocol STP + to block redundant paths. For an Ethernet network to + function properly, only one active path can exist between + two devices. STP will detect loops and + put the redundant links into a blocked state. Should one + of the active links fail, STP will + calculate a different tree and enable one of the blocked + paths to restore connectivity to all points in the + network. Kernel Configuration - This section covers &man.if.bridge.4; bridge - implementation, a netgraph bridging driver is also available, - for more information see &man.ng.bridge.4; manual page. + This section covers the &man.if.bridge.4; implementation. + A netgraph bridging driver is also available, and is described + in &man.ng.bridge.4;. - The bridge driver is a kernel module and will be + In &os;, &man.if.bridge.4; is a kernel module which is automatically loaded by &man.ifconfig.8; when creating a - bridge interface. It is possible to compile the bridge in to - the kernel by adding device if_bridge to - your kernel configuration file. + bridge interface. It is also possible to compile the bridge + in to the kernel by adding device if_bridge + to a custom kernel configuration file. Packet filtering can be used with any firewall package that hooks in via the &man.pfil.9; framework. The firewall can be loaded as a module or compiled into the kernel. The bridge can be used as a traffic shaper with &man.altq.4; or &man.dummynet.4;. Enabling the Bridge The bridge is created using interface cloning. To create - a bridge use &man.ifconfig.8;, if the bridge driver is not - present in the kernel then it will be loaded - automatically. + a bridge use &man.ifconfig.8;: &prompt.root; ifconfig bridge create bridge0 &prompt.root; ifconfig bridge0 bridge0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500 ether 96:3d:4b:f1:79:7a id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 0 ifcost 0 port 0 - A bridge interface is created and is automatically + When a bridge interface is created, it is automatically assigned a randomly generated Ethernet address. The maxaddr and timeout - parameters control how many MAC addresses the bridge will keep - in its forwarding table and how many seconds before each entry - is removed after it is last seen. The other parameters - control how Spanning Tree operates. + parameters control how many MAC addresses + the bridge will keep in its forwarding table and how many + seconds before each entry is removed after it is last seen. + The other parameters control how STP + operates. - Add the member network interfaces to the bridge. For the - bridge to forward packets all member interfaces and the bridge - need to be up: + Next, add the member network interfaces to the bridge. + For the bridge to forward packets, all member interfaces and + the bridge need to be up: &prompt.root; ifconfig bridge0 addm fxp0 addm fxp1 up &prompt.root; ifconfig fxp0 up &prompt.root; ifconfig fxp1 up The bridge is now forwarding Ethernet frames between fxp0 and - fxp1. The equivalent configuration - in /etc/rc.conf so the bridge is created - at startup is: + fxp1. Add the following lines to + /etc/rc.conf so the bridge is created + at startup: cloned_interfaces="bridge0" ifconfig_bridge0="addm fxp0 addm fxp1 up" ifconfig_fxp0="up" ifconfig_fxp1="up" - If the bridge host needs an IP address then the correct - place to set this is on the bridge interface itself rather - than one of the member interfaces. This can be set statically - or via DHCP: + If the bridge host needs an IP + address, the correct place to set this is on the bridge + interface itself rather than one of the member interfaces. + This can be set statically or via + DHCP: &prompt.root; ifconfig bridge0 inet 192.168.0.1/24 - It is also possible to assign an IPv6 address to a bridge - interface. + It is also possible to assign an IPv6 + address to a bridge interface. Firewalling firewall When packet filtering is enabled, bridged packets will - pass through the filter inbound on the originating interface, - on the bridge interface and outbound on the appropriate + pass through the filter inbound on the originating interface + on the bridge interface, and outbound on the appropriate interfaces. Either stage can be disabled. When direction of - the packet flow is important it is best to firewall on the + the packet flow is important, it is best to firewall on the member interfaces rather than the bridge itself. The bridge has several configurable settings for passing - non-IP and ARP packets, and layer2 firewalling with IPFW. See + non-IP and IP packets, + and layer2 firewalling with &man.ipfw.8;. See &man.if.bridge.4; for more information. Spanning Tree The bridge driver implements the Rapid Spanning Tree - Protocol (RSTP or 802.1w) with backwards compatibility with - the legacy Spanning Tree Protocol (STP). Spanning Tree is - used to detect and remove loops in a network topology. RSTP - provides faster Spanning Tree convergence than legacy STP, the - protocol will exchange information with neighbouring switches - to quickly transition to forwarding without creating - loops. - &os; supports RSTP and STP as operating modes, with RSTP - being the default mode. - - Spanning Tree can be enabled on member interfaces using - the stp command. For a bridge with + Protocol (RSTP or 802.1w) with backwards + compatibility with legacy STP. + STP is used to detect and remove loops + in a network topology. RSTP provides + faster convergence than legacy STP, the + protocol will exchange information with neighboring switches + to quickly transition to forwarding without creating loops. + &os; supports RSTP and + STP as operating modes, with + RSTP being the default mode. + + STP can be enabled on member interfaces + using &man.ifconfig.8;. For a bridge with fxp0 and fxp1 as the current interfaces, - enable STP with the following: + enable STP with: &prompt.root; ifconfig bridge0 stp fxp0 stp fxp1 bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 ether d6:cf:d5:a0:94:6d id 00:01:02:4b:d4:50 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:01:02:4b:d4:50 priority 32768 ifcost 0 port 0 member: fxp0 flags=1c7<LEARNING,DISCOVER,STP,AUTOEDGE,PTP,AUTOPTP> port 3 priority 128 path cost 200000 proto rstp role designated state forwarding member: fxp1 flags=1c7<LEARNING,DISCOVER,STP,AUTOEDGE,PTP,AUTOPTP> port 4 priority 128 path cost 200000 proto rstp role designated state forwarding This bridge has a spanning tree ID of 00:01:02:4b:d4:50 and a priority of 32768. As the root id - is the same it indicates that this is the root bridge for the + is the same, it indicates that this is the root bridge for the tree. - Another bridge on the network also has spanning tree - enabled: + Another bridge on the network also has + STP enabled: bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 ether 96:3d:4b:f1:79:7a id 00:13:d4:9a:06:7a priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:01:02:4b:d4:50 priority 32768 ifcost 400000 port 4 member: fxp0 flags=1c7<LEARNING,DISCOVER,STP,AUTOEDGE,PTP,AUTOPTP> port 4 priority 128 path cost 200000 proto rstp role root state forwarding member: fxp1 flags=1c7<LEARNING,DISCOVER,STP,AUTOEDGE,PTP,AUTOPTP> port 5 priority 128 path cost 200000 proto rstp role designated state forwarding The line root id 00:01:02:4b:d4:50 priority 32768 ifcost 400000 port 4 shows that the root bridge is - 00:01:02:4b:d4:50 as above and has a path - cost of 400000 from this bridge, the path - to the root bridge is via port 4 which is + 00:01:02:4b:d4:50 and has a path cost of + 400000 from this bridge. The path to the + root bridge is via port 4 which is fxp0. Advanced Bridging Reconstruct Traffic Flows The bridge supports monitor mode, where the packets are - discarded after &man.bpf.4; processing, and are not + discarded after &man.bpf.4; processing and are not processed or forwarded further. This can be used to multiplex the input of two or more interfaces into a single &man.bpf.4; stream. This is useful for reconstructing the traffic for network taps that transmit the RX/TX signals out through two separate interfaces. To read the input from four network interfaces as one stream: &prompt.root; ifconfig bridge0 addm fxp0 addm fxp1 addm fxp2 addm fxp3 monitor up &prompt.root; tcpdump -i bridge0 Span Ports A copy of every Ethernet frame received by the bridge will be transmitted out a designated span port. The number - of span ports configured on a bridge is unlimited, if an - interface is designated as a span port then it may not also - be used as a regular bridge port. This is most useful for + of span ports configured on a bridge is unlimited, but if an + interface is designated as a span port, it cannot also be + used as a regular bridge port. This is most useful for snooping a bridged network passively on another host connected to one of the span ports of the bridge. To send a copy of all frames out the interface named fxp4: &prompt.root; ifconfig bridge0 span fxp4 Private Interfaces A private interface does not forward any traffic to any other port that is also a private interface. The traffic is blocked unconditionally so no Ethernet frames will be - forwarded, including ARP. If traffic needs to be - selectively blocked then a firewall should be used + forwarded, including ARP. If traffic + needs to be selectively blocked, a firewall should be used instead. Sticky Interfaces - If a bridge member interface is marked as sticky then + If a bridge member interface is marked as sticky, dynamically learned address entries are treated at static once entered into the forwarding cache. Sticky entries are never aged out of the cache or replaced, even if the address is seen on a different interface. This gives the benefit of static address entries without the need to pre-populate the - forwarding table, clients learnt on a particular segment of - the bridge can not roam to another segment. + forwarding table. Clients learned on a particular segment + of the bridge can not roam to another segment. - Another example of using sticky addresses would be to - combine the bridge with VLANs to create a router where - customer networks are isolated without wasting IP address - space. Consider that + Another example of using sticky addresses is to + combine the bridge with VLANs to create + a router where customer networks are isolated without + wasting IP address space. Consider that CustomerA is on - vlan100 and - CustomerB is on + vlan100 and CustomerB is on vlan101. The bridge has the address 192.168.0.1 and is also an - internet router. + Internet router. &prompt.root; ifconfig bridge0 addm vlan100 sticky vlan100 addm vlan101 sticky vlan101 &prompt.root; ifconfig bridge0 inet 192.168.0.1/24 - Both clients see - 192.168.0.1 as their default - gateway and since the bridge cache is sticky they can not - spoof the MAC address of the other customer to intercept - their traffic. + In this example, both clients see 192.168.0.1 as their default + gateway. Since the bridge cache is sticky, one host can not + spoof the MAC address of the other + customer in order to intercept their traffic. - Any communication between the VLANs can be blocked using - private interfaces (or a firewall): + Any communication between the VLANs + can be blocked using a firewall or, as seen in this example, + private interfaces: &prompt.root; ifconfig bridge0 private vlan100 private vlan101 - The customers are completely isolated from each other, - the full /24 address range - can be allocated without subnetting. + The customers are completely isolated from each other + and the full /24 address + range can be allocated without subnetting. Address Limits - The number of unique source MAC addresses behind an - interface can be limited. Once the limit is reached packets - with unknown source addresses are dropped until an - existing host cache entry expires or is removed. + The number of unique source MAC + addresses behind an interface can be limited. Once the + limit is reached, packets with unknown source addresses + are dropped until an existing host cache entry expires or + is removed. The following example sets the maximum number of - Ethernet devices for - CustomerA on - vlan100 to 10. + Ethernet devices for CustomerA on + vlan100 to 10: &prompt.root; ifconfig bridge0 ifmaxaddr vlan100 10 - SNMP Monitoring - - The bridge interface and STP parameters can be monitored - via the SNMP daemon which is included in the &os; base - system. The exported bridge MIBs conform to the IETF - standards so any SNMP client or monitoring package can be + <acronym>SNMP</acronym> Monitoring + + The bridge interface and STP + parameters can be monitored via &man.bsnmpd.1; which is + included in the &os; base system. The exported bridge + MIBs conform to the + IETF standards so any + SNMP client or monitoring package can be used to retrieve the data. - On the bridge machine uncomment the + On the bridge, uncomment the begemotSnmpdModulePath."bridge" = "/usr/lib/snmp_bridge.so" line from - /etc/snmp.config and start the - bsnmpd daemon. Other - configuration such as community names and access lists may - need to be modified. See &man.bsnmpd.1; and - &man.snmp.bridge.3; for more information. + /etc/snmp.config and start + &man.bsnmpd.1;. Other configuration, such as community + names and access lists, may need to be modified. See + &man.bsnmpd.1; and &man.snmp.bridge.3; for more + information. The following examples use the - Net-SNMP software - (net-mgmt/net-snmp) to - query a bridge, the - net-mgmt/bsnmptools port - can also be used. From the SNMP client host add to - $HOME/.snmp/snmp.conf the following - lines to import the bridge MIB definitions in to - Net-SNMP: + Net-SNMP software (net-mgmt/net-snmp) to query a + bridge from a client system. The net-mgmt/bsnmptools port can + also be used. From the SNMP client + which is running Net-SNMP, add + the following lines to + $HOME/.snmp/snmp.conf in order to + import the bridge MIB definitions: mibdirs +/usr/share/snmp/mibs mibs +BRIDGE-MIB:RSTP-MIB:BEGEMOT-MIB:BEGEMOT-BRIDGE-MIB - To monitor a single bridge via the IETF BRIDGE-MIB - (RFC4188) do + To monitor a single bridge using the IETF BRIDGE-MIB + (RFC4188): &prompt.user; snmpwalk -v 2c -c public bridge1.example.com mib-2.dot1dBridge BRIDGE-MIB::dot1dBaseBridgeAddress.0 = STRING: 66:fb:9b:6e:5c:44 BRIDGE-MIB::dot1dBaseNumPorts.0 = INTEGER: 1 ports BRIDGE-MIB::dot1dStpTimeSinceTopologyChange.0 = Timeticks: (189959) 0:31:39.59 centi-seconds BRIDGE-MIB::dot1dStpTopChanges.0 = Counter32: 2 BRIDGE-MIB::dot1dStpDesignatedRoot.0 = Hex-STRING: 80 00 00 01 02 4B D4 50 ... BRIDGE-MIB::dot1dStpPortState.3 = INTEGER: forwarding(5) BRIDGE-MIB::dot1dStpPortEnable.3 = INTEGER: enabled(1) BRIDGE-MIB::dot1dStpPortPathCost.3 = INTEGER: 200000 BRIDGE-MIB::dot1dStpPortDesignatedRoot.3 = Hex-STRING: 80 00 00 01 02 4B D4 50 BRIDGE-MIB::dot1dStpPortDesignatedCost.3 = INTEGER: 0 BRIDGE-MIB::dot1dStpPortDesignatedBridge.3 = Hex-STRING: 80 00 00 01 02 4B D4 50 BRIDGE-MIB::dot1dStpPortDesignatedPort.3 = Hex-STRING: 03 80 BRIDGE-MIB::dot1dStpPortForwardTransitions.3 = Counter32: 1 RSTP-MIB::dot1dStpVersion.0 = INTEGER: rstp(2) - The dot1dStpTopChanges.0 value is two - which means that the STP bridge topology has changed twice, - a topology change means that one or more links in the - network have changed or failed and a new tree has been - calculated. The + The dot1dStpTopChanges.0 value is + two, indicating that the STP bridge + topology has changed twice. A topology change means that + one or more links in the network have changed or failed + and a new tree has been calculated. The dot1dStpTimeSinceTopologyChange.0 value will show when this happened. - To monitor multiple bridge interfaces one may use the - private BEGEMOT-BRIDGE-MIB: + To monitor multiple bridge interfaces, the private + BEGEMOT-BRIDGE-MIB can be used: &prompt.user; snmpwalk -v 2c -c public bridge1.example.com enterprises.fokus.begemot.begemotBridge BEGEMOT-BRIDGE-MIB::begemotBridgeBaseName."bridge0" = STRING: bridge0 BEGEMOT-BRIDGE-MIB::begemotBridgeBaseName."bridge2" = STRING: bridge2 BEGEMOT-BRIDGE-MIB::begemotBridgeBaseAddress."bridge0" = STRING: e:ce:3b:5a:9e:13 BEGEMOT-BRIDGE-MIB::begemotBridgeBaseAddress."bridge2" = STRING: 12:5e:4d:74:d:fc BEGEMOT-BRIDGE-MIB::begemotBridgeBaseNumPorts."bridge0" = INTEGER: 1 BEGEMOT-BRIDGE-MIB::begemotBridgeBaseNumPorts."bridge2" = INTEGER: 1 ... BEGEMOT-BRIDGE-MIB::begemotBridgeStpTimeSinceTopologyChange."bridge0" = Timeticks: (116927) 0:19:29.27 centi-seconds BEGEMOT-BRIDGE-MIB::begemotBridgeStpTimeSinceTopologyChange."bridge2" = Timeticks: (82773) 0:13:47.73 centi-seconds BEGEMOT-BRIDGE-MIB::begemotBridgeStpTopChanges."bridge0" = Counter32: 1 BEGEMOT-BRIDGE-MIB::begemotBridgeStpTopChanges."bridge2" = Counter32: 1 BEGEMOT-BRIDGE-MIB::begemotBridgeStpDesignatedRoot."bridge0" = Hex-STRING: 80 00 00 40 95 30 5E 31 BEGEMOT-BRIDGE-MIB::begemotBridgeStpDesignatedRoot."bridge2" = Hex-STRING: 80 00 00 50 8B B8 C6 A9 To change the bridge interface being monitored via the - mib-2.dot1dBridge subtree do: + mib-2.dot1dBridge subtree: &prompt.user; snmpset -v 2c -c private bridge1.example.com BEGEMOT-BRIDGE-MIB::begemotBridgeDefaultBridgeIf.0 s bridge2 Andrew Thompson Written by Link Aggregation and Failover lagg failover - fec - lacp + FEC + LACP loadbalance roundrobin Introduction The &man.lagg.4; interface allows aggregation of multiple network interfaces as one virtual interface for the purpose of providing fault-tolerance and high-speed links. Operating Modes + The following operating modes are supported by + &man.lagg.4;: + Failover Sends and receives traffic only through the master port. If the master port becomes unavailable, the next active port is used. The first interface added is the - master port; any interfaces added after that are used as - failover devices. If failover to a non-master port + master port and any interfaces added after that are used + as failover devices. If failover to a non-master port occurs, the original port will become master when it becomes available again. &cisco; Fast ðerchannel; - &cisco; Fast ðerchannel; (FEC), is a static setup - and does not negotiate aggregation with the peer or - exchange frames to monitor the link. If the switch - supports LACP then that should be used instead. + &cisco; Fast ðerchannel; (FEC) + is a static setup and does not negotiate aggregation + with the peer or exchange frames to monitor the link. + If the switch supports LACP, that + should be used instead. FEC balances outgoing traffic across the active ports based on hashed protocol header information and accepts incoming traffic from any active port. The hash includes the Ethernet source and - destination address, and, if available, the VLAN tag, - and the IPv4/IPv6 source and destination address. + destination address and, if available, the + VLAN tag, and the + IPv4 or IPv6 + source and destination address. - LACP + LACP The &ieee; 802.3ad Link Aggregation Control Protocol - (LACP) and the Marker Protocol. LACP will negotiate a - set of aggregable links with the peer in to one or more - Link Aggregated Groups (LAG). Each LAG is composed of - ports of the same speed, set to full-duplex operation. - The traffic will be balanced across the ports in the LAG - with the greatest total speed, in most cases there will - only be one LAG which contains all ports. In the event - of changes in physical connectivity, Link Aggregation - will quickly converge to a new configuration. + (LACP) and the Marker Protocol. + LACP will negotiate a set of + aggregable links with the peer in to one or more Link + Aggregated Groups (LAGs). Each + LAG is composed of ports of the + same speed, set to full-duplex operation. The traffic + will be balanced across the ports in the + LAG with the greatest total speed. + In most cases, there will only be one + LAG which contains all ports. In + the event of changes in physical connectivity, + LACP will quickly converge to a new + configuration. LACP balances outgoing traffic across the active ports based on hashed protocol header information and accepts incoming traffic from any active port. The hash includes the Ethernet source and - destination address, and, if available, the VLAN tag, - and the IPv4/IPv6 source and destination address. + destination address and, if available, the + VLAN tag, and the IPv4 or + IPv6 source and destination + address. Loadbalance This is an alias of FEC mode. Round-robin Distributes outgoing traffic using a round-robin scheduler through all active ports and accepts incoming traffic from any active port. This mode violates - Ethernet Frame ordering and should be used with + Ethernet frame ordering and should be used with caution. Examples - LACP Aggregation with a &cisco; Switch + <acronym>LACP</acronym> Aggregation with a &cisco; + Switch This example connects two interfaces on a &os; machine to the switch as a single load balanced and fault tolerant link. More interfaces can be added to increase throughput - and fault tolerance. Since frame ordering is mandatory on - Ethernet links then any traffic between two stations always - flows over the same physical link limiting the maximum speed - to that of one interface. The transmit algorithm attempts - to use as much information as it can to distinguish - different traffic flows and balance across the available - interfaces. - - On the &cisco; switch add the + and fault tolerance. Frame ordering is mandatory on + Ethernet links and any traffic between two stations always + flows over the same physical link, limiting the maximum + speed to that of one interface. The transmit algorithm + attempts to use as much information as it can to + distinguish different traffic flows and balance across the + available interfaces. + + On the &cisco; switch, add the FastEthernet0/1 and - FastEthernet0/2 interfaces to the - channel-group 1: + FastEthernet0/2 interfaces to + channel group 1: interface FastEthernet0/1 channel-group 1 mode active channel-protocol lacp ! interface FastEthernet0/2 channel-group 1 mode active channel-protocol lacp Create the &man.lagg.4; interface using fxp0 and fxp1, and bring the interfaces up - with the IP Address of + with the IP address of 10.0.0.3/24: &prompt.root; ifconfig fxp0 up &prompt.root; ifconfig fxp1 up &prompt.root; ifconfig lagg0 create &prompt.root; ifconfig lagg0 up laggproto lacp laggport fxp0 laggport fxp1 10.0.0.3/24 View the interface status by running: &prompt.root; ifconfig lagg0 Ports marked as ACTIVE are part of the active aggregation group that has been negotiated with - the remote switch and traffic will be transmitted and - received. Use the verbose output of &man.ifconfig.8; to - view the LAG identifiers. + the remote switch. Traffic will be transmitted and + received through active ports. Use the verbose output of + &man.ifconfig.8; to view the LAG + identifiers. lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=8<VLAN_MTU> ether 00:05:5d:71:8d:b8 media: Ethernet autoselect status: active laggproto lacp laggport: fxp1 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING> laggport: fxp0 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING> - To see the port status on the switch, use + To see the port status on the &cisco; switch, use show lacp neighbor: switch# show lacp neighbor Flags: S - Device is requesting Slow LACPDUs F - Device is requesting Fast LACPDUs A - Device is in Active mode P - Device is in Passive mode Channel group 1 neighbors Partner's information: LACP port Oper Port Port Port Flags Priority Dev ID Age Key Number State Fa0/1 SA 32768 0005.5d71.8db8 29s 0x146 0x3 0x3D Fa0/2 SA 32768 0005.5d71.8db8 29s 0x146 0x4 0x3D - For more detail use the show lacp neighbor - detail command. + For more detail, type show lacp neighbor + detail. To retain this configuration across reboots, the following entries can be added to /etc/rc.conf: ifconfig_fxp0="up" ifconfig_fxp1="up" cloned_interfaces="lagg0" ifconfig_lagg0="laggproto lacp laggport fxp0 laggport fxp1 10.0.0.3/24" Failover Mode Failover mode can be used to switch over to a secondary interface if the link is lost on the master interface. - Bring the underlying physical interfaces up. Create the - &man.lagg.4; interface, using - fxp0 as the master interface and - fxp1 as the secondary interface - and assign an IP Address of + To configure failover mode, first bring the underlying + physical interfaces up. Then, create the &man.lagg.4; + interface, using fxp0 as the + master interface and fxp1 as + the secondary interface, and assign an IP + address of 10.0.0.15/24: &prompt.root; ifconfig fxp0 up &prompt.root; ifconfig fxp1 up &prompt.root; ifconfig lagg0 create &prompt.root; ifconfig lagg0 up laggproto failover laggport fxp0 laggport fxp1 10.0.0.15/24 - The interface will look something like this, the major - differences will be the MAC address and - the device names: + The interface should now look something like + this: &prompt.root; ifconfig lagg0 lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=8<VLAN_MTU> ether 00:05:5d:71:8d:b8 inet 10.0.0.15 netmask 0xffffff00 broadcast 10.0.0.255 media: Ethernet autoselect status: active laggproto failover laggport: fxp1 flags=0<> laggport: fxp0 flags=5<MASTER,ACTIVE> Traffic will be transmitted and received on fxp0. If the link is lost on - fxp0 then + fxp0, fxp1 will become the active link. - If the link is restored on the master interface then it will + If the link is restored on the master interface, it will once again become the active link. To retain this configuration across reboots, the following entries can be added to /etc/rc.conf: ifconfig_fxp0="up" ifconfig_fxp1="up" cloned_interfaces="lagg0" ifconfig_lagg0="laggproto failover laggport fxp0 laggport fxp1 10.0.0.15/24" Failover Mode Between Wired and Wireless Interfaces - For laptop users, it is usually desirable to make - wireless as a secondary interface, which is to be used when - the wired connection is not available. With &man.lagg.4;, - it is possible to use one IP address, prefer the wired - connection for both performance and security reasons, while + For laptop users, it is usually desirable to configure + the wireless device as a secondary interface, which is used + when the wired connection is not available. With + &man.lagg.4;, it is possible to use one + IP address, prefer the wired connection + for both performance and security reasons, while maintaining the ability to transfer data over the wireless connection. - In this setup, we will need to override the underlying - wireless interface's MAC address to match - the &man.lagg.4;'s, which is inherited from the master - interface being used, the wired interface. - - In this setup, we will treat the wired interface, - bge0, as the master, and the - wireless interface, wlan0, as the - failover interface. The wlan0 - was created from iwn0 which we - will set up with the wired connection's - MAC address. The first step would be to - obtain the MAC address from the wired - interface: + In this setup, override the underlying wireless + interface's MAC address to match that + of the &man.lagg.4;, which is inherited from the wired + interface. + + In this example, the wired interface, + bge0, is the master, and the + wireless interface, wlan0, is + the failover interface. The + wlan0 device was created from + iwn0, which will be configured + with the wired connection's MAC address. + The first step is to determine the MAC + address of the wired interface: &prompt.root; ifconfig bge0 bge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=19b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4> ether 00:21:70:da:ae:37 inet6 fe80::221:70ff:feda:ae37%bge0 prefixlen 64 scopeid 0x2 nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> media: Ethernet autoselect (1000baseT <full-duplex>) status: active - You can replace the bge0 to - match your reality, and will get a different - ether line which is the - MAC address of your wired interface. - Now, we change the underlying wireless interface, - iwn0: + Replace bge0 to match the + system's interface name. The ether + line will contain the MAC address of + the wired interface. Now, change the + MAC address of the underlying wireless + interface: &prompt.root; ifconfig iwn0 ether 00:21:70:da:ae:37 - Bring the wireless interface up, but do not set an IP - address on it: + Bring the wireless interface up, but do not set an + IP address: &prompt.root; ifconfig wlan0 create wlandev iwn0 ssid my_router up Bring the bge0 interface up. Create the &man.lagg.4; interface with bge0 as master, and failover to - wlan0 if necessary: + wlan0: &prompt.root; ifconfig bge0 up &prompt.root; ifconfig lagg0 create &prompt.root; ifconfig lagg0 up laggproto failover laggport bge0 laggport wlan0 - The interface will look something like this, the major - differences will be the MAC address and - the device names: + The interface will now look something like this: &prompt.root; ifconfig lagg0 lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=8<VLAN_MTU> ether 00:21:70:da:ae:37 media: Ethernet autoselect status: active laggproto failover laggport: wlan0 flags=0<> laggport: bge0 flags=5<MASTER,ACTIVE> - Then start the DHCP client to obtain an IP - address: + Then, start the DHCP client to + obtain an IP address: &prompt.root; dhclient lagg0 To retain this configuration across reboots, the following entries can be added to /etc/rc.conf: ifconfig_bge0="up" ifconfig_iwn0="ether 00:21:70:da:ae:37" wlans_iwn0="wlan0" ifconfig_wlan0="WPA" cloned_interfaces="lagg0" ifconfig_lagg0="laggproto failover laggport bge0 laggport wlan0 DHCP" Jean-François Dockès Updated by Alex Dupre Reorganized and enhanced by Diskless Operation diskless workstation diskless operation - A FreeBSD machine can boot over the network and operate + A &os; machine can boot over the network and operate without a local disk, using file systems mounted from an NFS server. No system modification is necessary, beyond standard configuration files. Such a system is relatively easy to set up because all the necessary elements are readily available: - - - There are at least two possible methods to load the - kernel over the network: - - - - PXE: The &intel; Preboot - eXecution Environment system is a form of smart boot ROM - built into some networking cards or motherboards. See - &man.pxeboot.8; for more details. - - - - The Etherboot port - (net/etherboot) - produces ROM-able code to boot kernels over the network. - The code can be either burnt into a boot PROM on a - network card, or loaded from a local floppy (or hard) - disk drive, or from a running &ms-dos; system. Many - network cards are supported. - - - + The &intel; Preboot eXecution Environment + (PXE) can be used to load the kernel over + the network. It provides a form of smart boot + ROM built into some networking cards or + motherboards. See &man.pxeboot.8; for more details. - - A sample script - (/usr/share/examples/diskless/clone_root) - eases the creation and maintenance of the workstation's root - file system on the server. The script will probably require - a little customization but it will get you started very - quickly. - + A sample script + (/usr/share/examples/diskless/clone_root) + eases the creation and maintenance of the workstation's root + file system on the server. The script will probably require + a little customization. - - Standard system startup files exist - in /etc - to detect and support a diskless system startup. - + Standard system startup files exist in /etc to detect and support a + diskless system startup. - - Swapping, if needed, can be done either to an - NFS file or to a local disk. - - + Swapping, if needed, can be done either to an + NFS file or to a local disk. There are many ways to set up diskless workstations. Many elements are involved, and most can be customized to suit local taste. The following will describe variations on the setup of a complete system, emphasizing simplicity and compatibility with - the standard FreeBSD startup scripts. The system described has + the standard &os; startup scripts. The system described has the following characteristics: - The diskless workstations use a shared read-only - / file system, - and a shared read-only + The diskless workstations use a shared, read-only + / and /usr. - The root file system is a copy of a standard FreeBSD - root (typically the server's), with some configuration files - overridden by ones specific to diskless operation or, - possibly, to the workstation they belong to. + The root file system is a copy of a standard &os; + root, with some configuration files overridden by ones + specific to diskless operation or, possibly, to the + workstation they belong to. The parts of the root which have to be writable are overlaid with &man.md.4; file systems. Any changes will be lost when the system reboots. - - - The kernel is transferred and loaded either with - Etherboot or - PXE as some situations may mandate the - use of either method. - As described, this system is insecure. It should live in - a protected area of a network, and be untrusted by other + a protected area of a network and be untrusted by other hosts. - All the information in this section has been tested using - &os; 5.2.1-RELEASE. - Background Information Setting up diskless workstations is both relatively straightforward and prone to errors. These are sometimes difficult to diagnose for a number of reasons. For example: Compile time options may determine different behaviors at runtime. Error messages are often cryptic or totally absent. In this context, having some knowledge of the background - mechanisms involved is very useful to solve the problems that - may arise. + mechanisms involved is useful to solve the problems that may + arise. Several operations need to be performed for a successful bootstrap: The machine needs to obtain initial parameters such as - its IP address, executable filename, server name, root - path. This is done using the DHCP or - BOOTP protocols. DHCP is a compatible - extension of BOOTP, and uses the same port numbers and - basic packet format. - - It is possible to configure a system to use only - BOOTP. The &man.bootpd.8; server program is included in - the base &os; system. - - However, DHCP has a number of - advantages over BOOTP (nicer configuration files, - possibility of using PXE, plus many - others not directly related to diskless operation), and we - will describe mainly a DHCP + its IP address, executable filename, + server name, and root path. This is done using the + DHCP or BOOTP + protocols. DHCP is a compatible + extension of BOOTP, and uses the same + port numbers and basic packet format. It is possible to + configure a system to use only BOOTP + and &man.bootpd.8; is included in the base &os; + system. + + + + DHCP has a number of advantages + over BOOTP such as nicer configuration + files and support for PXE. This + section describes mainly a DHCP configuration, with equivalent examples using &man.bootpd.8; when possible. The sample configuration - will use the ISC DHCP software - package (release 3.0.1.r12 was installed on the test - server). + uses ISC DHCP which is + available in the Ports Collection. The machine needs to transfer one or several programs to local memory. Either TFTP or NFS are used. The choice between TFTP and NFS is a compile time option in several places. A common source of - error is to specify filenames for the wrong protocol: + error is to specify filenames for the wrong protocol. TFTP typically transfers all files from - a single directory on the server, and would expect - filenames relative to this directory. - NFS needs absolute file paths. + a single directory on the server and expects filenames + relative to this directory. NFS needs + absolute file paths. The possible intermediate bootstrap programs and the - kernel need to be initialized and executed. There are - several important variations in this area: - - - - - PXE will load &man.pxeboot.8;, - which is a modified version of the &os; third stage - loader. The &man.loader.8; will obtain most - parameters necessary to system startup, and leave them - in the kernel environment before transferring control. - It is possible to use a GENERIC - kernel in this case. - - - - Etherboot, will - directly load the kernel, with less preparation. You - will need to build a kernel with specific - options. - - - - PXE and - Etherboot work equally well; - however, because kernels normally let the &man.loader.8; - do more work for them, PXE is the - preferred method. - - If your BIOS and network cards - support PXE, you should probably use - it. + kernel need to be initialized and executed. + PXE loads &man.pxeboot.8;, which is + a modified version of the &os; third stage loader, + &man.loader.8;. The third stage loader will obtain most + parameters necessary to system startup and leave them + in the kernel environment before transferring control. + It is possible to use a GENERIC + kernel in this case. - Finally, the machine needs to access its file systems. - NFS is used in all cases. + Finally, the machine needs to access its file systems + using NFS. - See also &man.diskless.8; manual page. + Refer to &man.diskless.8; for more information. Setup Instructions Configuration Using <application>ISC DHCP</application> DHCP diskless operation The ISC DHCP server can - answer both BOOTP and DHCP - requests. + answer both BOOTP and + DHCP requests. - ISC DHCP 4.2 is not part of - the base system. You will first need to install the - net/isc-dhcp42-server - port or the corresponding package. + ISC DHCP is not part of + the base system. Install the net/isc-dhcp42-server port or + package. Once ISC DHCP is installed, - it needs a configuration file to run (normally named - /usr/local/etc/dhcpd.conf). Here - follows a commented example, where host - margaux uses - Etherboot and host - corbieres uses - PXE: + edit its configuration file, + /usr/local/etc/dhcpd.conf. Here + follows a commented example for PXE host + corbieres: default-lease-time 600; max-lease-time 7200; authoritative; option domain-name "example.com"; option domain-name-servers 192.168.4.1; option routers 192.168.4.1; subnet 192.168.4.0 netmask 255.255.255.0 { use-host-decl-names on; option subnet-mask 255.255.255.0; option broadcast-address 192.168.4.255; - host margaux { - hardware ethernet 01:23:45:67:89:ab; - fixed-address margaux.example.com; - next-server 192.168.4.4; - filename "/data/misc/kernel.diskless"; - option root-path "192.168.4.4:/data/misc/diskless"; - } host corbieres { hardware ethernet 00:02:b3:27:62:df; fixed-address corbieres.example.com; - next-server 192.168.4.4; - filename "pxeboot"; - option root-path "192.168.4.4:/data/misc/diskless"; + next-server 192.168.4.4; + filename "pxeboot"; + option root-path "192.168.4.4:/data/misc/diskless"; } } This option tells dhcpd to send the value in the host declarations as the hostname for the diskless host. An alternate way would be to add an option - host-name - margaux inside - the host declarations. + host-name corbieres + inside the host declarations. The next-server directive designates the TFTP or NFS server to use for loading - loader or kernel file (the default is to use the same - host as the DHCP server). + &man.loader.8; or the kernel file. The default is to + use the same host as the DHCP + server. - The filename directive - defines the file that - Etherboot or - PXE will load for the next execution - step. It must be specified according to the transfer - method used. Etherboot can - be compiled to use NFS or - TFTP. The &os; port configures - NFS by default. + The filename directive defines + the file that PXE will load for the + next execution step. It must be specified according + to the transfer method used. PXE uses TFTP, - which is why a relative filename is used here (this may - depend on the TFTP server - configuration, but would be fairly typical). Also, + which is why a relative filename is used here. Also, PXE loads pxeboot, not the kernel. There are other interesting possibilities, like loading pxeboot from a &os; CD-ROM - /boot directory - (as &man.pxeboot.8; can load a - GENERIC kernel, this makes it - possible to use PXE to boot from a - remote CD-ROM). + /boot directory. + Since &man.pxeboot.8; can load a + GENERIC kernel, it is possible to + use PXE to boot from a remote + CD-ROM. The root-path option defines the path to the root file system, in usual NFS notation. When using PXE, it is possible to leave off the - host's IP as long as you do not enable the kernel option - BOOTP. The NFS server will then be - the same as the TFTP one. + host's IP address as long as the + BOOTP kernel option is not enabled. + The NFS server will then be the + same as the TFTP one. - - Configuration Using BOOTP - - - BOOTP - diskless operation - - - Here follows an equivalent - bootpd configuration (reduced to - one client). This would be found in - /etc/bootptab. - - Please note that Etherboot - must be compiled with the non-default option - NO_DHCP_SUPPORT in order to use BOOTP, - and that PXE needs - DHCP. The only obvious advantage of - bootpd is that it exists in the - base system. - - .def100:\ - :hn:ht=1:sa=192.168.4.4:vm=rfc1048:\ - :sm=255.255.255.0:\ - :ds=192.168.4.1:\ - :gw=192.168.4.1:\ - :hd="/tftpboot":\ - :bf="/kernel.diskless":\ - :rp="192.168.4.4:/data/misc/diskless": - -margaux:ha=0123456789ab:tc=.def100 - - - - Preparing a Boot Program with - <application>Etherboot</application> - - - Etherboot - - - Etherboot's Web - site contains - extensive documentation mainly intended for Linux - systems, but nonetheless containing useful information. The - following will just outline how you would use - Etherboot on a FreeBSD - system. - - You must first install the - net/etherboot package or - port. - - You can change the Etherboot - configuration (i.e., to use TFTP instead - of NFS) by editing the - Config file in the - Etherboot source - directory. - - For our setup, we shall use a boot floppy. For other - methods (PROM, or &ms-dos; program), please refer to the - Etherboot documentation. - - To make a boot floppy, insert a floppy in the drive on - the machine where you installed - Etherboot, then change your - current directory to - the src - directory in the Etherboot tree and - type: - - &prompt.root; gmake bin32/devicetype.fd0 - - devicetype depends on the - type of the Ethernet card in the diskless workstation. - Refer to the NIC file in the same - directory to determine the right - devicetype. - - Booting with <acronym>PXE</acronym> - By default, the &man.pxeboot.8; loader loads the kernel - via NFS. It can be compiled to use + By default, &man.pxeboot.8; loads the kernel via + NFS. It can be compiled to use TFTP instead by specifying the LOADER_TFTP_SUPPORT option in /etc/make.conf. See the comments in /usr/share/examples/etc/make.conf for instructions. There are two other make.conf options which may be useful for setting up a serial console diskless machine: BOOT_PXELDR_PROBE_KEYBOARD, and BOOT_PXELDR_ALWAYS_SERIAL. To use PXE when the machine starts, - you will usually need to select the Boot from - network option in your BIOS - setup, or type a function key during the PC - initialization. + select the Boot from network option in + the BIOS setup or type a function key + during system initialization. Configuring the <acronym>TFTP</acronym> and <acronym>NFS</acronym> Servers TFTP diskless operation NFS diskless operation - If you are using PXE or - Etherboot configured to use - TFTP, you need to enable - tftpd on the file server: + If PXE is configured to use + TFTP, enable &man.tftpd.8; on the file + server: - Create a directory from which - tftpd will serve the files, - e.g., /tftpboot. + Create a directory from which &man.tftpd.8; will + serve the files, such as /tftpboot. - Add this line to your + Add this line to /etc/inetd.conf: tftp dgram udp wait root /usr/libexec/tftpd tftpd -l -s /tftpboot - It appears that at least some - PXE versions want the + Some + PXE versions require the TCP version of TFTP. In this case, add a second line, replacing dgram udp with stream tcp. - Tell inetd to reread its - configuration file. The - must be in the - /etc/rc.conf file for this command - to execute correctly: + Tell &man.inetd.8; to reread its configuration file. + Add to + /etc/rc.conf in order for this + command to execute correctly: &prompt.root; service inetd restart - You can place - the tftpboot - directory anywhere on the server. Make sure that the - location is set in both inetd.conf and - dhcpd.conf. + Place tftpboot + anywhere on the server. Make sure that the location is + set in both /etc/inetd.conf and + /usr/local/etc/dhcpd.conf. - In all cases, you also need to enable + Enable NFS and export the appropriate file system on the NFS server. - Add this to + Add this line to /etc/rc.conf: nfs_server_enable="YES" Export the file system where the diskless root directory is located by adding the following to - /etc/exports (adjust the volume - mount point and replace margaux + /etc/exports. Adjust the + mount point and replace corbieres with the names of the diskless - workstations): + workstations: /data/misc -alldirs -ro margaux corbieres - Tell mountd to reread its - configuration file. If you actually needed to enable - NFS in - /etc/rc.conf at the first step, you - probably want to reboot instead. + Tell &man.mountd.8; to reread its configuration + file. If NFS is enabled in + /etc/rc.conf, it is recommended + to reboot instead. &prompt.root; service mountd restart Building a Diskless Kernel diskless operation kernel configuration - If using Etherboot, you need - to create a kernel configuration file for the diskless - client with the following options (in addition to the usual - ones): + When using PXE, building a custom + kernel with the following options is not strictly necessary. + These options cause more DHCP requests + to be issued during kernel startup, with a small risk of + inconsistency between the new values and those retrieved + by &man.pxeboot.8; in some special cases. The advantage + is that the host name will be set. Otherwise, set the + host name in a client-specific + /etc/rc.conf. options BOOTP # Use BOOTP to obtain IP address/hostname options BOOTP_NFSROOT # NFS mount root file system using BOOTP info - You may also want to use BOOTP_NFSV3, + The custom kernel can also include + BOOTP_NFSV3, BOOT_COMPAT and - BOOTP_WIRED_TO (refer to - NOTES). + BOOTP_WIRED_TO. Refer to + NOTES for descriptions of these + options. These option names are historical and slightly misleading as they actually enable indifferent use of - DHCP and BOOTP inside the kernel (it is - also possible to force strict BOOTP or - DHCP use). - - Build the kernel (see ), - and copy it to the place specified in - dhcpd.conf. - - - When using PXE, building a kernel - with the above options is not strictly necessary (though - suggested). Enabling them will cause more - DHCP requests to be issued during - kernel startup, with a small risk of inconsistency between - the new values and those retrieved by &man.pxeboot.8; in - some special cases. The advantage of using them is that - the host name will be set as a side effect. Otherwise you - will need to set the host name by another method, for - example in a client-specific rc.conf - file. - + DHCP and BOOTP + inside the kernel. - - In order to be loadable with - Etherboot, a kernel needs to - have the device hints compiled in. You would typically - set the following option in the configuration file (see - the NOTES configuration comments - file): - - hints "GENERIC.hints" - + Build the custom kernel, using the instructions in + , and copy it to the place + specified in + /usr/local/etc/dhcpd.conf. - Preparing the Root Filesystem + Preparing the Root File System root file system diskless operation - You need to create a root file system for the diskless - workstations, in the location listed as + Create a root file system for the diskless + workstations in the location listed as root-path in - dhcpd.conf. + /usr/local/etc/dhcpd.conf. Using <command>make world</command> to Populate Root This method is quick and will install a complete - virgin system (not only the root file system) into - DESTDIR. All you have to do is simply - execute the following script: + virgin system, not just the root file system, into + DESTDIR. Execute the following + script: #!/bin/sh export DESTDIR=/data/misc/diskless mkdir -p ${DESTDIR} cd /usr/src; make buildworld && make buildkernel make installworld && make installkernel cd /usr/src/etc; make distribution - Once done, you may need to customize your + Once done, customize /etc/rc.conf and /etc/fstab placed into - DESTDIR according to your needs. + DESTDIR according to the system's + requirements. Configuring Swap If needed, a swap file located on the server can be accessed via NFS. <acronym>NFS</acronym> Swap The kernel does not support enabling NFS swap at boot time. Swap must be enabled by the startup scripts, by mounting a writable file system and creating and enabling a swap file. To - create a swap file of appropriate size, you can do like - this: + create a swap file: &prompt.root; dd if=/dev/zero of=/path/to/swapfile bs=1k count=1 oseek=100000 - To enable it you have to add the following line to - your rc.conf: + To enable the swap file, add the following line to + /etc/rc.conf: swapfile=/path/to/swapfile Miscellaneous Issues - Running with a Read-only - <filename class="directory">/usr</filename> + Running with a Read-only <filename + class="directory">/usr</filename> diskless operation /usr read-only - If the diskless workstation is configured to run X, - you will have to adjust the - XDM configuration file, which - puts the error log - on /usr by - default. + If the diskless workstation is configured to run + &xorg;, adjust the + XDM configuration file as it + puts the error log on /usr by default. - Using a Non-FreeBSD Server + Using a Non-&os; Server When the server for the root file system is not - running FreeBSD, you will have to create the root file - system on a FreeBSD machine, then copy it to its - destination, using tar or - cpio. + running &os;, create the root file system on a &os; + machine, then copy it to its destination, using + &man.tar.1; or &man.cpio.1;. In this situation, there are sometimes problems with - the special files - in /dev, due to - differing major/minor integer sizes. A solution to this - problem is to export a directory from the non-FreeBSD - server, mount this directory onto a FreeBSD machine, and - use &man.devfs.5; to allocate device nodes transparently - for the user. + the special files in /dev, due to differing + major/minor integer sizes. A solution to this problem + is to export a directory from the non-&os; server, mount + this directory onto a &os; machine, and use &man.devfs.5; + to allocate device nodes transparently for the + user. Craig Rodrigues
rodrigc@FreeBSD.org
 Written by - PXE Booting with an NFS Root File System + PXE Booting with an <acronym>NFS</acronym> Root File + System The &intel; Preboot eXecution Environment (PXE) allows booting the operating system over the network. PXE support is usually - provided in the BIOS of modern motherboards, - where it can be enabled in the BIOS settings - which enable booting from the network. A fully functioning + provided in the BIOS where it can be enabled + in the BIOS settings which enable booting + from the network. A fully functioning PXE setup also requires properly configured DHCP and TFTP servers. When the host computer boots, it receives information over DHCP about where to obtain the initial boot - loader via TFTP. After the host computer receives this - information, it downloads the boot loader via - TFTP, and then executes the boot loader. + loader via TFTP. After the host computer + receives this information, it downloads the boot loader via + TFTP and then executes the boot loader. This is documented in section 2.2.1 of the Preboot - Execution Environment (PXE) Specification. In &os;, - the boot loader retrieved during the PXE - process is /boot/pxeboot. After + Execution Environment (PXE) + Specification. In &os;, the boot loader retrieved + during the PXE process is + /boot/pxeboot. After /boot/pxeboot executes, the &os; kernel is - loaded, and the rest of the &os; bootup sequence proceeds. + loaded and the rest of the &os; bootup sequence proceeds. Refer to for more information about the &os; booting process. - Setting Up the <command>chroot</command> Environment for - the NFS Root File System + Setting Up the &man.chroot.8; Environment for the + <acronym>NFS</acronym> Root File System Choose a directory which will have a &os; - installation which will be NFS mountable. For example, a - directory such as - /b/tftpboot/FreeBSD/install can be - used. + installation which will be NFS + mountable. For example, a directory such as /b/tftpboot/FreeBSD/install + can be used. &prompt.root; export NFSROOTDIR=/b/tftpboot/FreeBSD/install &prompt.root; mkdir -p ${NFSROOTDIR} - Enable the NFS server by following the instructions - in . + Enable the NFS server by following + the instructions in . - Export the directory via NFS by adding the following - to /etc/exports: + Export the directory via NFS by + adding the following to + /etc/exports: /b -ro -alldirs - Restart the NFS server: + Restart the NFS server: &prompt.root; service nfsd restart Enable &man.inetd.8; by following the steps outlined in . Add the following line to /etc/inetd.conf: tftp dgram udp wait root /usr/libexec/tftpd tftpd -l -s /b/tftpboot - Restart inetd: + Restart &man.inetd.8;: &prompt.root; service inetd restart - Rebuild the &os; kernel and - userland: + Rebuild the &os; kernel and userland (): &prompt.root; cd /usr/src &prompt.root; make buildworld &prompt.root; make buildkernel Install &os; into the directory mounted over NFS: &prompt.root; make installworld DESTDIR=${NFSROOTDIR} &prompt.root; make installkernel DESTDIR=${NFSROOTDIR} &prompt.root; make distribution DESTDIR=${NFSROOTDIR} - Test that the TFTP server works and - can download the boot loader which will be obtained - via PXE: + Test that the TFTP server works + and can download the boot loader which will be obtained + via PXE: &prompt.root; tftp localhost tftp> get FreeBSD/install/boot/pxeboot Received 264951 bytes in 0.1 seconds Edit ${NFSROOTDIR}/etc/fstab and create an entry to mount the root file system over - NFS: + NFS: # Device Mountpoint FSType Options Dump Pass myhost.example.com:/b/tftpboot/FreeBSD/install / nfs ro 0 0 - Replace - myhost.example.com with the - hostname or IP address of your NFS - server. In this example, the root file system is mounted - "read-only" in order to prevent NFS - clients from potentially deleting the contents of the root - file system. + Replace myhost.example.com + with the hostname or IP address of the + NFS server. In this example, the root + file system is mounted read-only in order to prevent + NFS clients from potentially deleting + the contents of the root file system. Set the root password in the &man.chroot.8; - environment. + environment: &prompt.root; chroot ${NFSROOTDIR} &prompt.root; passwd - This will set the root password for client - machines which are PXE - booting. + This sets the root password for client machines which + are PXE booting. - Enable ssh root logins for client machines which are - PXE booting by editing - ${NFSROOTDIR}/etc/ssh/sshd_config and - enabling the PermitRootLogin option. - This is documented in &man.sshd.config.5;. + Enable &man.ssh.1; root logins for client machines + which are PXE booting by editing + ${NFSROOTDIR}/etc/ssh/sshd_config + and enabling PermitRootLogin. This + option is documented in &man.sshd.config.5;. Perform other customizations of the &man.chroot.8; environment in ${NFSROOTDIR}. These customizations could include things like adding packages with &man.pkg.add.1;, editing the password file with &man.vipw.8;, or editing &man.amd.conf.5; maps for automounting. For example: &prompt.root; chroot ${NFSROOTDIR} &prompt.root; pkg_add -r bash Configuring Memory File Systems Used by <filename>/etc/rc.initdiskless</filename> - If you boot from an NFS root volume, - /etc/rc detects that you booted over NFS - and runs the /etc/rc.initdiskless script. - Read the comments in this script to understand what is going - on. We need to - make /etc - and /var - memory backed file systems because - these directories need to be writable, but the NFS root - directory is read-only. + When booting from an NFS root volume, + /etc/rc detects the + NFS boot and runs + /etc/rc.initdiskless. Read the comments + in this script to understand what is going on. In this case, + /etc and /var need to be memory backed + file systems so that these directories are writable but the + NFS root directory is read-only: &prompt.root; chroot ${NFSROOTDIR} &prompt.root; mkdir -p conf/base &prompt.root; tar -c -v -f conf/base/etc.cpio.gz --format cpio --gzip etc &prompt.root; tar -c -v -f conf/base/var.cpio.gz --format cpio --gzip var - When the system boots, memory file systems - for /etc - and /var will - be created and mounted, and the contents of the + When the system boots, memory file systems for /etc and /var will be created and + mounted and the contents of the cpio.gz files will be copied into them. - Setting up the DHCP Server + Setting up the <acronym>DHCP</acronym> Server - PXE requires a TFTP server and a - DHCP server to be set up. The - DHCP server does not necessarily need to be - the same machine as the TFTP server, but it - needs to be accessible in your network. + PXE requires a TFTP + and a DHCP server to be set up. The + DHCP server does not need to be the same + machine as the TFTP server, but it needs + to be accessible in the network. Install the DHCP server by - following the instructions documented at - . Make sure that + following the instructions documented at . Make sure that /etc/rc.conf and /usr/local/etc/dhcpd.conf are correctly configured. In /usr/local/etc/dhcpd.conf, configure the next-server, filename, and - option root-path settings, to specify - your TFTP server IP address, the path - to /boot/pxeboot in - TFTP, and the path to the + option root-path settings to specify + the TFTP server IP + address, the path to /boot/pxeboot + in TFTP, and the path to the NFS root file system. Here is a sample dhcpd.conf setup: subnet 192.168.0.0 netmask 255.255.255.0 { range 192.168.0.2 192.168.0.3 ; option subnet-mask 255.255.255.0 ; option routers 192.168.0.1 ; option broadcast-address 192.168.0.255 ; option domain-name-server 192.168.35.35, 192.168.35.36 ; option domain-name "example.com"; # IP address of TFTP server next-server 192.168.0.1 ; # path of boot loader obtained # via tftp filename "FreeBSD/install/boot/pxeboot" ; # pxeboot boot loader will try to NFS mount this directory for root FS option root-path "192.168.0.1:/b/tftpboot/FreeBSD/install/" ; } - Configuring the PXE Client and Debugging Connection - Problems + Configuring the <acronym>PXE</acronym> Client and + Debugging Connection Problems When the client machine boots up, enter the BIOS configuration menu. Configure the BIOS to boot from the network. If all - your previous configuration steps are correct, then - everything should "just work". + previous configuration steps are correct, everything + should "just work". - Use the - net/wireshark port to - debug the network traffic involved during the - PXE booting process, which is - illustrated in the diagram below. In - , an example + Use the net/wireshark package or + port to debug the network traffic involved during the + PXE booting process, as illustrated + in the diagram below. In , an example configuration is shown where the DHCP, TFTP, and NFS - servers are actually on the same machine. However, these - severs can be on separate machines. + servers are on the same machine. However, these + servers can be on separate machines.
- PXE Booting Process with NFS Root Mount + <acronym>PXE</acronym> Booting Process with + <acronym>NFS</acronym> Root Mount - Client broadcasts DHCPDISCOVER. + Client broadcasts a + DHCPDISCOVER message. - DHCP server responds with IP address, + The DHCP server responds + with the IP address, next-server, filename, and - root-path. + root-path values. - Client sends TFTP - request to next-server + The client sends a TFTP + request to next-server, asking to retrieve filename. - TFTP server responds and sends - filename to client. + The TFTP server responds + and sends filename to + client. - Client executes - filename which is - &man.pxeboot.8;. &man.pxeboot.8; loads the - kernel. When the kernel executes, the root - filesystem specified by - root-path is mounted over - NFS. + The client executes + filename, which is + &man.pxeboot.8;, which then loads the kernel. + When the kernel executes, the root file system + specified by root-path is + mounted over NFS.
Make sure that the pxeboot file - can be retrieved by TFTP. On your - TFTP server, look in + can be retrieved by TFTP. On the + TFTP server, read /var/log/xferlog to ensure that the pxeboot file is being retrieved from - the correct location. To test the configuration from - dhcpd.conf above: + the correct location. To test this example + configuration: &prompt.root; tftp 192.168.0.1 tftp> get FreeBSD/install/boot/pxeboot Received 264951 bytes in 0.1 seconds - Read &man.tftpd.8; and &man.tftp.1;. The - BUGS sections in these pages document - some limitations with TFTP. + The BUGS sections in &man.tftpd.8; + and &man.tftp.1; document some limitations with + TFTP. Make sure that the root file system can be mounted - via NFS. To test configuration from - dhcpd.conf above: + via NFS. To test this example + configuration: &prompt.root; mount -t nfs 192.168.0.1:/b/tftpboot/FreeBSD/install /mnt Read the code in src/sys/boot/i386/libi386/pxe.c to understand how the pxeboot loader sets variables like boot.nfsroot.server and boot.nfsroot.path. These variables - are then used in the NFS diskless root mount code in + are then used in the NFS diskless root + mount code in src/sys/nfsclient/nfs_diskless.c. Read &man.pxeboot.8; and &man.loader.8;. - - ISDN - - - ISDN - - - A good resource for information on ISDN technology and - hardware is - Dan - Kegel's ISDN Page. - - A quick simple road map to ISDN follows: - - - - If you live in Europe you might want to investigate the - ISDN card section. - - - - If you are planning to use ISDN primarily to connect to - the Internet with an Internet Provider on a dial-up - non-dedicated basis, you might look into Terminal Adapters. - This will give you the most flexibility, with the fewest - problems, if you change providers. - - - - If you are connecting two LANs together, or connecting - to the Internet with a dedicated ISDN connection, you might - consider the stand alone router/bridge option. - - - - Cost is a significant factor in determining what solution - you will choose. The following options are listed from least - expensive to most expensive. - - - - - - Hellmuth - Michaelis - Contributed by - - - - ISDN Cards - - - ISDN - cards - - - FreeBSD's ISDN implementation supports only the DSS1/Q.931 - (or Euro-ISDN) standard using passive cards. Some active - cards are supported where the firmware also supports other - signaling protocols; this also includes the first supported - Primary Rate (PRI) ISDN card. - - The isdn4bsd software allows - you to connect to other ISDN routers using either IP over raw - HDLC or by using synchronous PPP: either by using kernel PPP - with isppp, a modified &man.sppp.4; driver, - or by using userland &man.ppp.8;. By using userland - &man.ppp.8;, channel bonding of two or more ISDN B-channels is - possible. A telephone answering machine application is also - available as well as many utilities such as a software 300 - Baud modem. - - Some growing number of PC ISDN cards are supported under - FreeBSD and the reports show that it is successfully used all - over Europe and in many other parts of the world. - - The passive ISDN cards supported are mostly the ones with - the Infineon (formerly Siemens) ISAC/HSCX/IPAC ISDN chipsets, - but also ISDN cards with chips from Cologne Chip (ISA bus - only), PCI cards with Winbond W6692 chips, some cards with the - Tiger300/320/ISAC chipset combinations and some vendor - specific chipset based cards such as the AVM Fritz!Card PCI - V.1.0 and the AVM Fritz!Card PnP. - - Currently the active supported ISDN cards are the AVM B1 - (ISA and PCI) BRI cards and the AVM T1 PCI PRI cards. - - For documentation on isdn4bsd, - have a look at the - homepage of - isdn4bsd which also has pointers to hints, erratas - and much more documentation such as the isdn4bsd - handbook. - - In case you are interested in adding support for a - different ISDN protocol, a currently unsupported ISDN PC card - or otherwise enhancing isdn4bsd, - please get in touch with &a.hm;. - - For questions regarding the installation, configuration - and troubleshooting isdn4bsd, a - &a.isdn.name; mailing list is available. - - - - ISDN Terminal Adapters - - Terminal adapters (TA), are to ISDN what modems are to - regular phone lines. - - modem - Most TA's use the standard Hayes modem AT command set, and - can be used as a drop in replacement for a modem. - - A TA will operate basically the same as a modem except - connection and throughput speeds will be much faster than your - old modem. You will need to configure - PPP exactly the same as for a modem - setup. Make sure you set your serial speed as high as - possible. - - PPP - The main advantage of using a TA to connect to an Internet - Provider is that you can do Dynamic PPP. As IP address space - becomes more and more scarce, most providers are not willing - to provide you with a static IP any more. Most stand-alone - routers are not able to accommodate dynamic IP - allocation. - - TA's completely rely on the PPP daemon that you are - running for their features and stability of connection. This - allows you to upgrade easily from using a modem to ISDN on a - FreeBSD machine, if you already have PPP set up. However, at - the same time any problems you experienced with the PPP - program and are going to persist. - - If you want maximum stability, use the kernel - PPP option, not the - userland PPP. - - The following TA's are known to work with FreeBSD: - - - - Motorola BitSurfer and Bitsurfer Pro - - - - Adtran - - - - Most other TA's will probably work as well, TA vendors try - to make sure their product can accept most of the standard - modem AT command set. - - The real problem with external TA's is that, like modems, - you need a good serial card in your computer. - - You should read the FreeBSD Serial - Hardware tutorial for a detailed understanding of - serial devices, and the differences between asynchronous and - synchronous serial ports. - - A TA running off a standard PC serial port (asynchronous) - limits you to 115.2 Kbs, even though you have a - 128 Kbs connection. To fully utilize the 128 Kbs - that ISDN is capable of, you must move the TA to a synchronous - serial card. - - Do not be fooled into buying an internal TA and thinking - you have avoided the synchronous/asynchronous issue. Internal - TA's simply have a standard PC serial port chip built into - them. All this will do is save you having to buy another - serial cable and find another empty electrical socket. - - A synchronous card with a TA is at least as fast as a - stand-alone router, and with a simple 386 FreeBSD box driving - it, probably more flexible. - - The choice of synchronous card/TA versus stand-alone - router is largely a religious issue. There has been some - discussion of this in the mailing lists. We suggest you - search the - archives for - the complete discussion. - - - - Stand-alone ISDN Bridges/Routers - - - ISDN - stand-alone bridges/routers - - ISDN bridges or routers are not at all specific to FreeBSD - or any other operating system. For a more complete - description of routing and bridging technology, please refer - to a networking reference book. - - In the context of this section, the terms router and - bridge will be used interchangeably. - - As the cost of low end ISDN routers/bridges comes down, it - will likely become a more and more popular choice. An ISDN - router is a small box that plugs directly into your local - Ethernet network, and manages its own connection to the other - bridge/router. It has built in software to communicate via - PPP and other popular protocols. - - A router will allow you much faster throughput than a - standard TA, since it will be using a full synchronous ISDN - connection. - - The main problem with ISDN routers and bridges is that - interoperability between manufacturers can still be a problem. - If you are planning to connect to an Internet provider, you - should discuss your needs with them. - - If you are planning to connect two LAN segments together, - such as your home LAN to the office LAN, this is the simplest - lowest - maintenance solution. Since you are buying the equipment for - both sides of the connection you can be assured that the link - will work. - - For example to connect a home computer or branch office - network to a head office network the following setup could be - used: - - - Branch Office or Home Network - - 10 base 2 - Network uses a bus based topology with 10 base 2 - Ethernet (thinnet). Connect router to - network cable with AUI/10BT transceiver, if - necessary. - - - - - - - - ---Sun workstation -| ----FreeBSD box -| ----Windows 95 -| -Stand-alone router - | -ISDN BRI line - - - - 10 Base 2 Ethernet - - - - If your home/branch office is only one computer you can - use a twisted pair crossover cable to connect to the - stand-alone router directly. - - - - Head Office or Other LAN - - 10 base T - Network uses a star topology with 10 base T Ethernet - (Twisted Pair). - - - - - - - - -------Novell Server - | H | - | ---Sun - | | - | U ---FreeBSD - | | - | ---Windows 95 - | B | - |___---Stand-alone router - | - ISDN BRI line - - - - ISDN Network Diagram - - - - - One large advantage of most routers/bridges is that they - allow you to have 2 separate independent - PPP connections to 2 separate sites at the - same time. This is not supported on most - TA's, except for specific (usually expensive) models that have - two serial ports. Do not confuse this with channel bonding, - MPP, etc. - - This can be a very useful feature if, for example, you - have an dedicated ISDN connection at your office and would - like to tap into it, but do not want to get another ISDN line - at work. A router at the office location can manage a - dedicated B channel connection (64 Kbps) to the Internet - and use the other B channel for a separate data connection. - The second B channel can be used for dial-in, dial-out or - dynamically bonding (MPP, etc.) with the first B channel for - more bandwidth. - - IPX/SPX - An Ethernet bridge will also allow you to transmit more - than just IP traffic. You can also send IPX/SPX or whatever - other protocols you use. - - - Chern Lee Contributed by Network Address Translation Overview - natd + &man.natd.8; - FreeBSD's Network Address Translation daemon, commonly - known as &man.natd.8; is a daemon that accepts incoming raw IP - packets, changes the source to the local machine and - re-injects these packets back into the outgoing IP packet - stream. &man.natd.8; does this by changing the source IP - address and port such that when data is received back, it is - able to determine the original location of the data and - forward it back to its original requester. + &os;'s Network Address Translation + (NAT) daemon, &man.natd.8;, accepts + incoming raw IP packets, changes the + source to the local machine, and injects these packets back + into the outgoing IP packet stream. The + source IP address and port are changed + such that when data is received back, it is able to determine + the original location of the data and forward it back to its + original requester. Internet connection sharing - NAT + NAT - The most common use of NAT is to perform what is commonly - known as Internet Connection Sharing. + The most common use of NAT is to + perform what is commonly known as Internet Connection + Sharing. Setup - Due to the diminishing IP space in IPv4, and the increased - number of users on high-speed consumer lines such as cable or - DSL, people are increasingly in need of an Internet Connection - Sharing solution. The ability to connect several computers - online through one connection and IP address makes - &man.natd.8; a reasonable choice. + Due to the diminishing IP address + space in IPv4 and the increased number of + users on high-speed consumer lines such as cable or + DSL, people are increasingly in need of + an Internet Connection Sharing solution. The ability to + connect several computers online through one connection and + IP address makes &man.natd.8; a reasonable + choice. Most commonly, a user has a machine connected to a cable - or DSL line with one IP address and wishes to use this one - connected computer to provide Internet access to several more - over a LAN. - - To do this, the FreeBSD machine on the Internet must act - as a gateway. This gateway machine must have two - NICs—one for connecting to the Internet router, the - other connecting to a LAN. All the machines on the LAN are - connected through a hub or switch. + or DSL line with one IP + address and wishes to use this one connected computer to + provide Internet access to several more over a + LAN. + + To do this, the &os; machine connected to the Internet + must act as a gateway. This gateway machine must have two + NICs: one connects to the Internet router + and the other connects to a LAN. All the + machines on the LAN are connected through + a hub or switch. - There are many ways to get a LAN connected to the - Internet through a &os; gateway. This example will only - cover a gateway with at least two NICs. + There are many ways to get a LAN + connected to the Internet through a &os; gateway. This + example will only cover a gateway with at least two + NICs. _______ __________ ________ | | | | | | | Hub |-----| Client B |-----| Router |----- Internet |_______| |__________| |________| | ____|_____ | | | Client A | |__________| Network Layout A setup like this is commonly used to share an Internet connection. One of the LAN machines is - connected to the Internet. The rest of the machines access + connected to the Internet and the rest of the machines access the Internet through that gateway machine. Boot Loader Configuration boot loader configuration - The kernel features for network address translation with - &man.natd.8; are not enabled in the - GENERIC kernel, but they can be preloaded - at boot time, by adding a couple of options to + The kernel features for &man.natd.8; are not enabled in + the GENERIC kernel, but they can be + loaded at boot time by adding a couple of options to /boot/loader.conf: ipfw_load="YES" ipdivert_load="YES" Additionally, the net.inet.ip.fw.default_to_accept tunable - option may be set to 1: + option should be set to 1: net.inet.ip.fw.default_to_accept="1" - It is a very good idea to set this option during the - first attempts to setup a firewall and NAT gateway. This - way the default policy of &man.ipfw.8; will be - allow ip from any to any instead of the - less permissive deny ip from any to any, - and it will be slightly more difficult to get locked out of - the system right after a reboot. + It is a good idea to set this option during the first + attempts to setup a firewall and NAT + gateway. This sets the default policy of &man.ipfw.8; to + be more permissive than the default deny ip from + any to any, making it slightly more difficult + to get locked out of the system right after a reboot. Kernel Configuration kernel configuration - When modules are not an option or if it is preferrable to - build all the required features into the running kernel, the - following options must be in the kernel configuration + When modules are not an option or if it is preferable to + build all the required features into a custom kernel, the + following options must be in the custom kernel configuration file: options IPFIREWALL options IPDIVERT - Additionally, at choice, the following may also be - suitable: + Additionally, the following may also be suitable: options IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_VERBOSE System Startup Configuration - To enable firewall and NAT support at boot time, the - following must be in /etc/rc.conf: + To enable firewall and NAT support at + boot time, the following must be in + /etc/rc.conf: gateway_enable="YES" firewall_enable="YES" firewall_type="OPEN" natd_enable="YES" natd_interface="fxp0" natd_flags="" Sets up the machine to act as a gateway. Running sysctl net.inet.ip.forwarding=1 would have the same effect. Enables the firewall rules in /etc/rc.firewall at boot. This specifies a predefined firewall ruleset that allows anything in. See /etc/rc.firewall for additional types. - Indicates which interface to forward packets through - (the interface connected to the Internet). + Indicates which interface to forward packets through. + This is the interface that is connected to the + Internet. Any additional configuration options passed to &man.natd.8; on boot. - Having the previous options defined in - /etc/rc.conf would run + These + /etc/rc.conf options will run natd -interface fxp0 at boot. This can - also be run manually. + also be run manually after boot. It is also possible to use a configuration file for &man.natd.8; when there are too many options to pass. In this case, the configuration file must be defined by adding the following line to /etc/rc.conf: natd_flags="-f /etc/natd.conf" - The /etc/natd.conf file will - contain a list of configuration options, one per line. For - example the next section case would use the following - file: + A list of configuration options, one per line, can be + added to /etc/natd.conf. For + example: redirect_port tcp 192.168.0.2:6667 6667 redirect_port tcp 192.168.0.3:80 80 - For more information about the configuration file, - consult the &man.natd.8; manual page about the - option. + For more information about this configuration file, + consult &man.natd.8;. - Each machine and interface behind the LAN should be - assigned IP address numbers in the private network space as - defined by - RFC - 1918 and have a default gateway of the - natd machine's internal IP + Each machine and interface behind the + LAN should be assigned + IP addresses in the private network space, + as defined by RFC + 1918, and have a default gateway of the + &man.natd.8; machine's internal IP address. For example, client A and - B behind the LAN have IP addresses of - 192.168.0.2 and - 192.168.0.3, while the natd - machine's LAN interface has an IP address of - 192.168.0.1. Client - A and B's default gateway - must be set to that of the natd - machine, 192.168.0.1. The - natd machine's external, or - Internet interface does not require any special modification - for &man.natd.8; to work. + B behind the LAN have + IP addresses of 192.168.0.2 and 192.168.0.3, while the &man.natd.8; + machine's LAN interface has an + IP address of 192.168.0.1. The default gateway + of clients A and B must be + set to that of the &man.natd.8; machine, 192.168.0.1. The &man.natd.8; + machine's external Internet interface does not require any + special modification for &man.natd.8; to work. Port Redirection - The drawback with &man.natd.8; is that the LAN clients are - not accessible from the Internet. Clients on the LAN can make + The drawback with &man.natd.8; is that the + LAN clients are not accessible from the + Internet. Clients on the LAN can make outgoing connections to the world but cannot receive incoming ones. This presents a problem if trying to run Internet - services on one of the LAN client machines. A simple way - around this is to redirect selected Internet ports on the - natd machine to a LAN + services on one of the LAN client machines. + A simple way around this is to redirect selected Internet + ports on the &man.natd.8; machine to a LAN client. - For example, an IRC server runs on client - A, and a web server runs on client + For example, an IRC server runs on + client A and a web server runs on client B. For this to work properly, connections - received on ports 6667 (IRC) and 80 (web) must be redirected - to the respective machines. + received on ports 6667 (IRC) and 80 + (HTTP) must be redirected to the + respective machines. - The must be passed to - &man.natd.8; with the proper options. The syntax is as + The syntax for is as follows: -redirect_port proto targetIP:targetPORT[-targetPORT] [aliasIP:]aliasPORT[-aliasPORT] [remoteIP[:remotePORT[-remotePORT]]] In the above example, the argument should be: -redirect_port tcp 192.168.0.2:6667 6667 -redirect_port tcp 192.168.0.3:80 80 - This will redirect the proper tcp - ports to the LAN client machines. + This redirects the proper TCP ports + to the LAN client machines. - The argument can be used - to indicate port ranges over individual ports. For example, + Port ranges over individual ports can be indicated with + . For example, tcp 192.168.0.2:2000-3000 2000-3000 would redirect all connections received on ports 2000 to 3000 to ports 2000 to 3000 on client A. These options can be used when directly running &man.natd.8;, placed within the natd_flags="" option in /etc/rc.conf, or passed via a configuration file. For further configuration options, consult &man.natd.8; Address Redirection address redirection - Address redirection is useful if several IP addresses are - available, yet they must be on one machine. With this, - &man.natd.8; can assign each LAN client its own external IP - address. &man.natd.8; then rewrites outgoing packets from the - LAN clients with the proper external IP address and redirects - all traffic incoming on that particular IP address back to the - specific LAN client. This is also known as static NAT. For - example, the IP addresses - 128.1.1.1, - 128.1.1.2, and - 128.1.1.3 belong to the - natd gateway machine. - 128.1.1.1 can be used as the - natd gateway machine's external IP + Address redirection is useful if more than one + IP address is available. Each + LAN client can be assigned its own + external IP address by &man.natd.8;, + which will then rewrite outgoing packets from the + LAN clients with the proper external + IP address and redirects all traffic + incoming on that particular IP address + back to the specific LAN client. This is + also known as static NAT. For example, + if IP addresses 128.1.1.1, 128.1.1.2, and 128.1.1.3 are available, 128.1.1.1 can be used as the + &man.natd.8; machine's external IP address, while 128.1.1.2 and - 128.1.1.3 are forwarded back to - LAN clients A and B. + 128.1.1.3 are forwarded back + to LAN clients A and + B. The syntax is as follows: -redirect_address localIP publicIP localIP - The internal IP address of the LAN - client. + The internal IP address of + the LAN client. publicIP - The external IP address corresponding to the LAN + The external IP address + corresponding to the LAN client. In the example, this argument would read: -redirect_address 192.168.0.2 128.1.1.2 -redirect_address 192.168.0.3 128.1.1.3 Like , these arguments are - also placed within the natd_flags="" option + placed within the natd_flags="" option of /etc/rc.conf, or passed via a configuration file. With address redirection, there is no need for port redirection since all data received on a - particular IP address is redirected. + particular IP address is redirected. - The external IP addresses on the - natd machine must be active and - aliased to the external interface. Look at &man.rc.conf.5; to - do so. + The external IP addresses on the + &man.natd.8; machine must be active and aliased to the + external interface. Refer to &man.rc.conf.5; for + details. Aaron Kaplan Originally Written by Tom Rhodes Restructured and Added by Brad Davis Extended by - IPv6 + <acronym>IPv6</acronym> - IPv6 (also known as IPng IP next generation) - is the new version of the well known IP protocol (also known as - IPv4). Like the other current *BSD systems, - FreeBSD includes the KAME IPv6 reference implementation. So - your FreeBSD system comes with all you will need to experiment - with IPv6. This section focuses on getting IPv6 configured and - running. + IPv6, also known as + IPng IP next + generation, is the new version of the well known + IP protocol, also known as + IPv4. &os; includes the KAME + IPv6 reference implementation. &os; comes + with everything needed to use IPv6. This + section focuses on getting IPv6 configured + and running. In the early 1990s, people became aware of the rapidly - diminishing address space of IPv4. Given the expansion rate of - the Internet there were two major concerns: + diminishing address space of IPv4. Given + the expansion rate of the Internet, there were two major + concerns: Running out of addresses. Today this is not so much of - a concern any more, since RFC1918 private address space - (10.0.0.0/8, - 172.16.0.0/12, and - 192.168.0.0/16) and Network - Address Translation (NAT) are being - employed. + a concern, since RFC1918 private address space (10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16) and + NAT are being employed. Router table entries were getting too large. This is still a concern today. - IPv6 deals with these and many other issues: + IPv6 deals with these and many other + issues by providing the following: - 128 bit address space. In other words theoretically - there are + 128 bit address space which allows for 340,282,366,920,938,463,463,374,607,431,768,211,456 - addresses available. This means there are approximately - 6.67 * 10^27 IPv6 addresses per square meter on our - planet. + addresses. This means there are approximately + 6.67 * 10^27 IPv6 addresses per square + meter on the planet. - Routers will only store network aggregation addresses in - their routing tables thus reducing the average space of a + Routers only store network aggregation addresses in + their routing tables, thus reducing the average space of a routing table to 8192 entries. - There are also lots of other useful features of IPv6 such - as: + There are other useful features of + IPv6: Address autoconfiguration (RFC2462) + url="http://www.ietf.org/rfc/rfc2462.txt">RFC2462). Anycast addresses (one-out-of - many) + many). - Mandatory multicast addresses + Mandatory multicast addresses. - IPsec (IP security) + IPsec (IP + security). - Simplified header structure + Simplified header structure. - Mobile IP + Mobile IP. - IPv6-to-IPv4 transition mechanisms + IPv6-to-IPv4 + transition mechanisms. For more information see: KAME.net - Background on IPv6 Addresses + Background on <acronym>IPv6</acronym> Addresses - There are different types of IPv6 addresses: Unicast, - Anycast and Multicast. + There are different types of IPv6 + addresses: unicast, anycast, and multicast. Unicast addresses are the well known addresses. A packet - sent to a unicast address arrives exactly at the interface + sent to a unicast address arrives at the interface belonging to the address. Anycast addresses are syntactically indistinguishable from unicast addresses but they address a group of interfaces. The packet destined for an anycast address will arrive at the nearest (in router metric) interface. Anycast addresses may only be used by routers. Multicast addresses identify a group of interfaces. A packet destined for a multicast address will arrive at all interfaces belonging to the multicast group. - The IPv4 broadcast address (usually - xxx.xxx.xxx.255) is expressed - by multicast addresses in IPv6. + The IPv4 broadcast address, usually + xxx.xxx.xxx.255, is expressed + by multicast addresses in IPv6. - Reserved IPv6 Addresses + Reserved <acronym>IPv6</acronym> Addresses - IPv6 address + IPv6 address Prefixlength (Bits) Description Notes :: 128 bits unspecified - cf. 0.0.0.0 in - IPv4 + Equivalent to 0.0.0.0 in + IPv4. ::1 128 bits loopback address - cf. 127.0.0.1 in - IPv4 + Equivalent to 127.0.0.1 in + IPv4. ::00:xx:xx:xx:xx 96 bits - embedded IPv4 - The lower 32 bits are the IPv4 address. Also - called IPv4 compatible IPv6 - address + embedded IPv4 + The lower 32 bits are the compatible + IPv4 address. ::ff:xx:xx:xx:xx 96 bits - IPv4 mapped IPv6 address - The lower 32 bits are the IPv4 address. - For hosts which do not support IPv6. + IPv4 mapped + IPv6 address + The lower 32 bits are the IPv4 + address for hosts which do not support + IPv6. fe80:: - feb:: 10 bits link-local - cf. loopback address in IPv4 + Equivalent to the loopback address in + IPv4. fec0:: - fef:: 10 bits site-local   ff:: 8 bits multicast   001 (base 2) 3 bits global unicast All global unicast addresses are assigned from this pool. The first 3 bits are 001.
- Reading IPv6 Addresses + Reading <acronym>IPv6</acronym> Addresses The canonical form is represented as: - x:x:x:x:x:x:x:x, each - x being a 16 Bit hex value. For example + x:x:x:x:x:x:x:x, with each + x being a 16 bit hex value. For example: FEBC:A574:382B:23C1:AA49:4592:4EFE:9982 + role="ip6addr">FEBC:A574:382B:23C1:AA49:4592:4EFE:9982. - Often an address will have long substrings of all zeros - therefore one such substring per address can be abbreviated by - ::. Also up to three leading 0s - per hexquad can be omitted. For example + Often an address will have long substrings of all zeros. + One such substring per address can be abbreviated by + ::. Also, up to three leading + 0s per hex quad can be omitted. For example, fe80::1 corresponds to the canonical form fe80:0000:0000:0000:0000:0000:0000:0001. - A third form is to write the last 32 Bit part in the - well known (decimal) IPv4 style with dots . - as separators. For example - 2002::10.0.0.1 - corresponds to the (hexadecimal) canonical representation - 2002:0000:0000:0000:0000:0000:0a00:0001 - which in turn is equivalent to writing - 2002::a00:1. + A third form is to write the last 32 bit part in the + well known (decimal) IPv4 style with dots + (.) as separators. For example, 2002::10.0.0.1 corresponds to the + hexadecimal canonical representation 2002:0000:0000:0000:0000:0000:0a00:0001, + which in turn is equivalent to 2002::a00:1. - By now the reader should be able to understand the - following: + Here is a sample entry from &man.ifconfig.8;: &prompt.root; ifconfig rl0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500 inet 10.0.0.10 netmask 0xffffff00 broadcast 10.0.0.255 inet6 fe80::200:21ff:fe03:8e1%rl0 prefixlen 64 scopeid 0x1 ether 00:00:21:03:08:e1 media: Ethernet autoselect (100baseTX ) status: active fe80::200:21ff:fe03:8e1%rl0 - is an auto configured link-local address. It is generated - from the MAC address as part of the auto configuration. + role="ip6addr">fe80::200:21ff:fe03:8e1%rl0 is an + auto configured link-local address. It is generated from + the MAC address as part of the auto + configuration. - For further information on the structure of IPv6 addresses - see For further information on the structure of + IPv6 addresses, see RFC3513. Getting Connected - Currently there are four ways to connect to other IPv6 - hosts and networks: + Currently, there are four ways to connect to other + IPv6 hosts and networks: - Contact your Internet Service Provider to see if they - offer IPv6 yet. + Contact an Internet Service Provider to see if they + offer IPv6. SixXS offers tunnels with end-points all around the globe. - Tunnel via 6-to-4 (RFC3068) + Tunnel via 6-to-4 as described in RFC3068. Use the - net/freenet6 port if - you are on a dial-up connection. + net/freenet6 port + for a dial-up connection. - DNS in the IPv6 World + <acronym>DNS</acronym> in the <acronym>IPv6</acronym> + World - There used to be two types of DNS records for IPv6. The - IETF has declared A6 records obsolete. AAAA records are the - standard now. + There used to be two types of DNS + records for IPv6. The + IETF has declared AAAA + records as the current standard. - Using AAAA records is straightforward. Assign your - hostname to the new IPv6 address you just received by - adding: + Using AAAA records is straightforward. + Assign the hostname to the IPv6 address + in the primary zone DNS file: MYHOSTNAME AAAA MYIPv6ADDR - To your primary zone DNS file. In case you do not serve - your own DNS zones ask your - DNS provider. Current versions of - bind (version 8.3 and 9) and - dns/djbdns (with the IPv6 - patch) support AAAA records. + Current versions of &man.named.8; and dns/djbdns support + AAAA records. Applying the Needed Changes to <filename>/etc/rc.conf</filename> - IPv6 Client Settings + <acronym>IPv6</acronym> Client Settings - These settings will help you configure a machine that - will be on your LAN and act as a client, not a router. To - have &man.rtsol.8; autoconfigure your interface on boot on - &os; 9.x and later, - add: + These settings configure a machine on a + LAN which acts as a client, not a + router. To instruct &man.rtsol.8; to autoconfigure the + interface on boot on + &os; 9.x and later, add + this line to rc.conf: ipv6_prefer="YES" - to rc.conf. - - For &os; 8.x and - earlier, add: + For &os; 8.x, + add: ipv6_enable="YES" - To statically assign an IP address such as To statically assign the IPv6 + address, 2001:471:1f11:251:290:27ff:fee0:2093, - to your fxp0 interface, add the - following for + to fxp0, add the following for &os; 9.x: ifconfig_fxp0_ipv6="inet6 2001:471:1f11:251:290:27ff:fee0:2093 prefixlen 64" Be sure to change prefixlen - 64 to the appropriate value for the subnet - within which the computer is networked. + 64 to the appropriate value for the + subnet. - For &os; 8x and earlier, + For &os; 8x, add: ipv6_ifconfig_fxp0="2001:471:1f11:251:290:27ff:fee0:2093" - To assign a default router of - 2001:471:1f11:251::1 add the + To assign a default router of 2001:471:1f11:251::1, add the following to /etc/rc.conf: ipv6_defaultrouter="2001:471:1f11:251::1" - IPv6 Router/Gateway Settings + <acronym>IPv6</acronym> Router/Gateway Settings - This will help you take the directions that your tunnel - provider has given you and convert it into settings that - will persist through reboots. To restore your tunnel on - startup use something like the following in - /etc/rc.conf: + This section demonstrates how to take the directions + from a tunnel provider and convert it into settings that + will persist through reboots. To restore the tunnel on + startup, add the following lines to + /etc/rc.conf. - List the Generic Tunneling interfaces that will be - configured, for example + The first entry lists the generic tunneling interfaces + to be configured. This example configures one interface, gif0: gif_interfaces="gif0" - To configure the interface with a local endpoint of + To configure that interface with a local endpoint of MY_IPv4_ADDR to a remote endpoint of REMOTE_IPv4_ADDR: gifconfig_gif0="MY_IPv4_ADDR REMOTE_IPv4_ADDR" - To apply the IPv6 address you have been assigned for use - as your IPv6 tunnel endpoint, add the following for + To apply the IPv6 address that has + been assigned for use as the IPv6 tunnel + endpoint, add the following line for &os; 9.x and later: ifconfig_gif0_ipv6="inet6 MY_ASSIGNED_IPv6_TUNNEL_ENDPOINT_ADDR" - For &os; 8.x and - earlier, add: + For &os; 8.x, + add: ipv6_ifconfig_gif0="MY_ASSIGNED_IPv6_TUNNEL_ENDPOINT_ADDR" - Then all you have to do is set the default route for - IPv6. This is the other side of the IPv6 tunnel: + Then, set the default route for + IPv6. This is the other side of the + IPv6 tunnel: ipv6_defaultrouter="MY_IPv6_REMOTE_TUNNEL_ENDPOINT_ADDR" - IPv6 Tunnel Settings + <acronym>IPv6</acronym> Tunnel Settings - If the server is to route IPv6 between the rest of your - network and the world, the following + If the server is to route IPv6 + between the rest of the network and the world, the following /etc/rc.conf setting will also be needed: ipv6_gateway_enable="YES" Router Advertisement and Host Auto Configuration - This section will help you setup &man.rtadvd.8; to - advertise the IPv6 default route. + This section demonstrates how to setup &man.rtadvd.8; to + advertise the IPv6 default route. - To enable &man.rtadvd.8; you will need the following in - your /etc/rc.conf: + To enable &man.rtadvd.8;, add the following to + /etc/rc.conf: rtadvd_enable="YES" - It is important that you specify the interface on which to - do IPv6 router solicitation. For example to tell - &man.rtadvd.8; to use fxp0: + It is important to specify the interface on which to + do IPv6 router solicitation. For example, + to tell &man.rtadvd.8; to use + fxp0: rtadvd_interfaces="fxp0" - Now we must create the configuration file, - /etc/rtadvd.conf. Here is an + Next, create the configuration file, + /etc/rtadvd.conf as seen in this example: fxp0:\ :addrs#1:addr="2001:471:1f11:246::":prefixlen#64:tc=ether: Replace fxp0 with the interface - you are going to be using. + to be used and 2001:471:1f11:246:: with the + prefix of the allocation. - Next, replace - 2001:471:1f11:246:: with the - prefix of your allocation. + For a dedicated /64 + subnet, nothing else needs to be changed. Otherwise, change + the prefixlen# to the correct value. + - If you are dedicated a /64 - subnet you will not need to change anything else. Otherwise, - you will need to change the prefixlen# to - the correct value. + + <acronym>IPv6</acronym> and <acronym>IPv6</acronym> + Address Mapping + + When IPv6 is enabled on a server, there + may be a need to enable IPv4 mapped + IPv6 address communication. This + compatibility option allows for IPv4 + addresses to be represented as IPv6 + addresses. Permitting IPv6 applications + to communicate with IPv4 and vice versa + may be a security issue. + + This option may not be required in most cases and is + available only for compatibility. This option will allow + IPv6-only applications to work with + IPv4 in a dual stack environment. This + is most useful for third party applications which may not + support an IPv6-only environment. To + enable this feature, + add the following to /etc/rc.conf: + + ipv6_ipv4mapping="YES" + + Reviewing the information in RFC 3493, + section 3.6 and 3.7 as well as RFC 4038 + section 4.2 may be useful to some adminstrators. Harti Brandt Contributed by - Asynchronous Transfer Mode (ATM) + Asynchronous Transfer Mode (<acronym>ATM</acronym>) - Configuring Classical IP over ATM (PVCs) - - Classical IP over ATM (CLIP) is the - simplest method to use Asynchronous Transfer Mode (ATM) - with IP. It can be used with - switched connections (SVCs) and with permanent connections - (PVCs). This section describes how to set up a network based - on PVCs. + Configuring Classical <acronym>IP</acronym> over + <acronym>ATM</acronym> + + Classical IP over + ATM (CLIP) is the + simplest method to use Asynchronous Transfer Mode + (ATM) with IP. It can + be used with Switched Virtual Circuits + (SVCs) and with Permanent Virtual Circuits + (PVCs). This section describes how to + set up a network based on PVCs. Fully Meshed Configurations The first method to set up a CLIP - with PVCs is to connect each machine to each other machine - in the network via a dedicated PVC. While this is simple to - configure it tends to become impractical for a larger number - of machines. The example supposes that we have four - machines in the network, each connected to the - ATM - network with an - ATM - adapter card. The first step is the planning of the IP - addresses and the - ATM - connections between the machines. We use the + with PVCs is to connect each machine + to each other machine in the network via a dedicated + PVC. While this is simple to + configure, it becomes impractical for a large number of + machines. The following example supposes four machines in + the network, each connected to the ATM network + with an ATM adapter + card. The first step is the planning of the + IP addresses and the ATM + connections between the machines. This example uses the following: Host - IP Address + IP Address hostA 192.168.173.1 hostB 192.168.173.2 hostC 192.168.173.3 hostD 192.168.173.4 - To build a fully meshed net we need one ATM connection - between each pair of machines: + To build a fully meshed net, one ATM + connection is needed between each pair of machines: Machines VPI.VCI couple hostA - hostB 0.100 hostA - hostC 0.101 hostA - hostD 0.102 hostB - hostC 0.103 hostB - hostD 0.104 hostC - hostD 0.105 - The VPI and VCI values at each end of the connection may - of course differ, but for simplicity we assume that they are - the same. Next we need to configure the ATM interfaces on - each host: + The Virtual Path Identifier VPI and + Virtual Channel Identifier VCI values + at each end of the connection may differ, but for + simplicity, this example assumes they are the same. Next, + configure the ATM interfaces on each + host: hostA&prompt.root; ifconfig hatm0 192.168.173.1 up hostB&prompt.root; ifconfig hatm0 192.168.173.2 up hostC&prompt.root; ifconfig hatm0 192.168.173.3 up hostD&prompt.root; ifconfig hatm0 192.168.173.4 up - assuming that the ATM interface is - hatm0 on all hosts. Now the PVCs - need to be configured on hostA (we assume - that they are already configured on the ATM switches, you - need to consult the manual for the switch on how to do - this). + This example assumes that the ATM + interface is hatm0 on all hosts. + Next, the PVCs need to be configured on + hostA. This should already be configured + on the ATM switch; consult the manual + for the switch on how to do this. hostA&prompt.root; atmconfig natm add 192.168.173.2 hatm0 0 100 llc/snap ubr hostA&prompt.root; atmconfig natm add 192.168.173.3 hatm0 0 101 llc/snap ubr hostA&prompt.root; atmconfig natm add 192.168.173.4 hatm0 0 102 llc/snap ubr hostB&prompt.root; atmconfig natm add 192.168.173.1 hatm0 0 100 llc/snap ubr hostB&prompt.root; atmconfig natm add 192.168.173.3 hatm0 0 103 llc/snap ubr hostB&prompt.root; atmconfig natm add 192.168.173.4 hatm0 0 104 llc/snap ubr hostC&prompt.root; atmconfig natm add 192.168.173.1 hatm0 0 101 llc/snap ubr hostC&prompt.root; atmconfig natm add 192.168.173.2 hatm0 0 103 llc/snap ubr hostC&prompt.root; atmconfig natm add 192.168.173.4 hatm0 0 105 llc/snap ubr hostD&prompt.root; atmconfig natm add 192.168.173.1 hatm0 0 102 llc/snap ubr hostD&prompt.root; atmconfig natm add 192.168.173.2 hatm0 0 104 llc/snap ubr hostD&prompt.root; atmconfig natm add 192.168.173.3 hatm0 0 105 llc/snap ubr - Of course other traffic contracts than UBR can be used - given the ATM adapter supports those. In this case the name - of the traffic contract is followed by the parameters of the - traffic. Help for the &man.atmconfig.8; tool can be - obtained with: + Other traffic contracts besides ubr + can be used if the ATM adapter supports + it. In this case, the name of the traffic contract is + followed by the parameters of the traffic. Help for the + &man.atmconfig.8; tool can be obtained with: &prompt.root; atmconfig help natm add - or in the &man.atmconfig.8; manual page. + Refer to &man.atmconfig.8; for more information. The same configuration can also be done via - /etc/rc.conf. For - hostA this would look like: + /etc/rc.conf. These lines configure + hostA: network_interfaces="lo0 hatm0" ifconfig_hatm0="inet 192.168.173.1 up" natm_static_routes="hostB hostC hostD" route_hostB="192.168.173.2 hatm0 0 100 llc/snap ubr" route_hostC="192.168.173.3 hatm0 0 101 llc/snap ubr" route_hostD="192.168.173.4 hatm0 0 102 llc/snap ubr" The current state of all CLIP routes can be obtained with: hostA&prompt.root; atmconfig natm show Tom Rhodes Contributed by - Common Address Redundancy Protocol (CARP) + Common Address Redundancy Protocol + (<acronym>CARP</acronym>) - CARP + CARP Common Address Redundancy Protocol - The Common Address Redundancy Protocol, or - CARP allows multiple hosts to share the same - IP address. In some configurations, this may - be used for availability or load balancing. Hosts may use - separate IP addresses as well, as in the + The Common Address Redundancy Protocol + (CARP) allows multiple hosts to share the + same IP address. In some configurations, + this may be used for availability or load balancing. Hosts + may use separate IP addresses, as in the example provided here. To enable support for CARP, the &os; - kernel must be rebuilt as described in - with the following option: + kernel can be rebuilt as described in with the following option: device carp Alternatively, the if_carp.ko module - can be loaded at boot time. Add the following line to the + can be loaded at boot time. Add the following line to /boot/loader.conf: if_carp_load="YES" CARP functionality should now be - available and may be tuned via several sysctl - OIDs: + available and may be tuned via several &man.sysctl.8; + variables: OID Description net.inet.carp.allow Accept incoming CARP packets. Enabled by default. net.inet.carp.preempt This option downs all of the CARP interfaces on the host when one - of them goes down. Disabled by default + goes down. Disabled by default. net.inet.carp.log A value of 0 disables any - logging. A Value of 1 enables + logging. A value of 1 enables logging of bad CARP packets. Values - greater than 1 enables logging of + greater than 1 enable logging of state changes for the CARP interfaces. The default value is 1. net.inet.carp.arpbalance Balance local network traffic using ARP. Disabled by default. net.inet.carp.suppress_preempt - A read only OID showing the - status of preemption suppression. Preemption can be - suppressed if link on an interface is down. A value of - 0, means that preemption is not + A read-only variable showing the status of + preemption suppression. Preemption can be suppressed + if the link on an interface is down. A value of + 0 means that preemption is not suppressed. Every problem increments this - OID. + variable. The CARP devices themselves may be - created via the ifconfig command: + created using &man.ifconfig.8;: &prompt.root; ifconfig carp0 create - In a real environment, these interfaces will need unique - identification numbers known as a VHID. This - VHID or Virtual Host Identification will be - used to distinguish the host on the network. + In a real environment, each interface has a unique + identification number known as a Virtual Host IDentification + (VHID) which is used to distinguish the + host on the network. - Using CARP for Server Availability (CARP) + Using <acronym>CARP</acronym> for Server + Availability - One use of CARP, as noted above, is for - server availability. This example will provide failover - support for three hosts, all with unique IP + One use of CARP is to provide server + availability. This example configures failover support for + three hosts, all with unique IP addresses and providing the same web content. These machines - will act in conjunction with a Round Robin + act in conjunction with a Round Robin DNS configuration. The failover machine - will have two additional CARP interfaces, - one for each of the content server's IPs. - When a failure occurs, the failover server should pick up the - failed machine's IP address. This means - the failure should go completely unnoticed to the user. The - failover server requires identical content and services as the - other content servers it is expected to pick up load - for. + has two additional CARP interfaces, one + for each of the content server's + IP addresses. When a + failure occurs, the failover server will pick up the failed + machine's IP address. + This means that the failure should go completely unnoticed + by the user. The failover server requires identical content + and services as the other content servers it is expected to + pick up load for. The two machines should be configured identically other - than their issued hostnames and VHIDs. - This example calls these machines + than their hostnames and VHIDs. This + example calls these machines hosta.example.org and hostb.example.org respectively. First, the required lines for a CARP configuration - have to be added to rc.conf. For - hosta.example.org, the - rc.conf file should contain the following - lines: + have to be added to /etc/rc.conf. Here + are the lines for + hosta.example.org: hostname="hosta.example.org" ifconfig_fxp0="inet 192.168.1.3 netmask 255.255.255.0" cloned_interfaces="carp0" ifconfig_carp0="vhid 1 pass testpass 192.168.1.50/24" - On hostb.example.org the following lines - should be in rc.conf: + On hostb.example.org, use the following + lines: hostname="hostb.example.org" ifconfig_fxp0="inet 192.168.1.4 netmask 255.255.255.0" cloned_interfaces="carp0" ifconfig_carp0="vhid 2 pass testpass 192.168.1.51/24" It is very important that the passwords, specified by - the option to - ifconfig, are identical. The - carp devices will only listen to - and accept advertisements from machines with the correct - password. The VHID must also be - different for each machine. + the option to &man.ifconfig.8;, are + identical. The carp devices will + only listen to and accept advertisements from machines + with the correct password. The VHID + must also be unique for each machine. The third machine, provider.example.org, should be prepared so that it may handle failover from either host. This machine will require two carp devices, one to handle each - host. The appropriate rc.conf + host. The appropriate /etc/rc.conf configuration lines will be similar to the following: hostname="provider.example.org" ifconfig_fxp0="inet 192.168.1.5 netmask 255.255.255.0" cloned_interfaces="carp0 carp1" ifconfig_carp0="vhid 1 advskew 100 pass testpass 192.168.1.50/24" ifconfig_carp1="vhid 2 advskew 100 pass testpass 192.168.1.51/24" Having the two carp devices will allow provider.example.org to notice and pick - up the IP address of either machine should + up the IP address of either machine, should it stop responding. The default &os; kernel may have preemption enabled. If so, provider.example.org may not relinquish the IP address back to the original content server. In this case, an administrator may have to manually - force the IP back to the master. The following command - should be issued on + force the IP back to the master. The + following command should be issued on provider.example.org: &prompt.root; ifconfig carp0 down && ifconfig carp0 up This should be done on the carp interface which corresponds to the correct host. - At this point, CARP should be - completely enabled and available for testing. For testing, - either networking has to be restarted or the machines need to - be rebooted. + At this point, CARP should be enabled + and available for testing. For testing, either networking + has to be restarted or the machines rebooted. - More information is always available in the &man.carp.4; - manual page. + More information is available in &man.carp.4;. diff --git a/en_US.ISO8859-1/books/handbook/audit/chapter.xml b/en_US.ISO8859-1/books/handbook/audit/chapter.xml index 5d5540e5f6..e666e6a91e 100644 --- a/en_US.ISO8859-1/books/handbook/audit/chapter.xml +++ b/en_US.ISO8859-1/books/handbook/audit/chapter.xml @@ -1,750 +1,744 @@ Tom Rhodes Written by Robert Watson Security Event Auditing Synopsis AUDIT Security Event Auditing MAC The &os; operating system includes support for fine-grained security event auditing. Event auditing allows the reliable, fine-grained, and configurable logging of a variety of security-relevant system events, including logins, configuration changes, and file and network access. These log records can be invaluable for live system monitoring, intrusion detection, and postmortem analysis. &os; implements &sun;'s published BSM API and file format, and is interoperable with both &sun;'s &solaris; and &apple;'s &macos; X audit implementations. This chapter focuses on the installation and configuration of Event Auditing. It explains audit policies, and provides an example audit configuration. After reading this chapter, you will know: What Event Auditing is and how it works. - How to configure Event Auditing on &os; for users - and processes. + How to configure Event Auditing on &os; for users and + processes. How to review the audit trail using the audit reduction and review tools. Before reading this chapter, you should: Understand &unix; and &os; basics (). Be familiar with the basics of kernel configuration/compilation (). - Have some familiarity with security and how it - pertains to &os; (). + Have some familiarity with security and how it pertains + to &os; (). The audit facility has some known limitations which include that not all security-relevant system events are currently auditable, and that some login mechanisms, such as X11-based display managers and third party daemons, do not properly configure auditing for user login sessions. The security event auditing facility is able to generate very detailed logs of system activity: on a busy system, trail file data can be very large when configured for high detail, exceeding gigabytes a week in some configurations. Administrators should take into account disk space requirements associated with high volume audit configurations. For example, it may be desirable to dedicate a file system to - the /var/audit tree so that other file - systems are not affected if the audit file system becomes - full. + the /var/audit tree + so that other file systems are not affected if the audit file + system becomes full. Key Terms in This Chapter Before reading this chapter, a few key audit-related terms must be explained: event: An auditable event is any event that can be logged using the audit subsystem. Examples of security-relevant events include the creation of a file, the building of a network connection, or a user logging in. Events are either attributable, meaning that they can be traced to an authenticated user, or non-attributable if they cannot be. Examples of non-attributable events are any events that occur before authentication in the login process, such as bad password attempts. class: Event classes are named sets of related events, and are used in selection expressions. - Commonly used classes of events include - file creation (fc), exec (ex) - and login_logout (lo). + Commonly used classes of events include file + creation (fc), exec (ex) and + login_logout (lo). record: A record is an audit log entry describing a security event. Records contain a record event type, information on the subject (user) performing the action, date and time information, information on any objects or arguments, and a success or failure condition. trail: An audit trail, or log file, consists of a series of audit records describing security events. Typically, trails are in roughly chronological order with respect to the time events completed. Only authorized processes are allowed to commit records to the audit trail. selection expression: A selection expression is a string containing a list of prefixes and audit event class names used to match events. preselection: The process by which the system identifies which events are of interest to the administrator in order to avoid generating audit records describing events that are not of interest. The preselection configuration uses a series of selection expressions to identify which classes of events to audit for which users, as well as global settings that apply to both authenticated and unauthenticated processes. reduction: The process by which records from existing audit trails are selected for preservation, printing, or analysis. Likewise, the process by which undesired audit records are removed from the audit trail. Using reduction, administrators can implement policies for the preservation of audit data. For example, detailed audit trails might be kept for one month, but after that, trails might be reduced in order to preserve only login information for archival purposes. Installing Audit Support User space support for Event Auditing is installed as part of the base &os; operating system. Kernel support for Event Auditing is compiled in by default, but support for this feature must be explicitly compiled into the custom kernel by adding the following line to the kernel configuration file: options AUDIT Rebuild and reinstall - the kernel via the normal process explained in - . + the kernel via the normal process explained in . Once an audit-enabled kernel is built, installed, and the system has been rebooted, enable the audit daemon by adding the following line to &man.rc.conf.5;: auditd_enable="YES" Audit support must then be started by a reboot, or by manually starting the audit daemon: service auditd start Audit Configuration All configuration files for security audit are found in /etc/security. The following files must be present before the audit daemon is started: audit_class - Contains the definitions of the audit classes. audit_control - Controls aspects of the audit subsystem, such as default audit classes, minimum disk space to leave on the audit log volume, maximum audit trail size, etc. audit_event - Textual names and descriptions of system audit events, as well as a list of which classes each event is in. audit_user - User-specific audit requirements, which are combined with the global defaults at login. audit_warn - A customizable shell - script used by auditd to generate - warning messages in exceptional situations, such as when - space for audit records is running low or when the audit - trail file has been rotated. + script used by &man.auditd.8; to generate warning messages + in exceptional situations, such as when space for audit + records is running low or when the audit trail file has + been rotated. Audit configuration files should be edited and maintained carefully, as errors in configuration may result in improper logging of events. Event Selection Expressions Selection expressions are used in a number of places in the audit configuration to determine which events should be audited. Expressions contain a list of event classes to match, each with a prefix indicating whether matching records should be accepted or ignored, and optionally to indicate if the entry is intended to match successful or failed operations. Selection expressions are evaluated from left to right, and two expressions are combined by appending one onto the other. The following list contains the default audit event classes present in audit_class: all - all - Match all event classes. ad - administrative - Administrative actions performed on the system as a whole. ap - application - Application defined action. cl - file close - Audit calls to the close system call. ex - exec - Audit program execution. Auditing of command line arguments and environmental variables is controlled via &man.audit.control.5; using the argv and envv parameters to the policy setting. fa - file attribute access - Audit the access of object attributes such as &man.stat.1;, &man.pathconf.2; and similar events. fc - file create - Audit events where a file is created as a result. fd - file delete - Audit events where file deletion occurs. fm - file attribute modify - Audit events where file attribute modification occurs, such as &man.chown.8;, &man.chflags.1;, &man.flock.2;, etc. fr - file read - Audit events in which data is read, files are opened for reading, etc. fw - file write - Audit events in which data is written, files are written or modified, etc. io - ioctl - Audit use of the &man.ioctl.2; system call. ip - ipc - Audit various forms of Inter-Process Communication, including POSIX pipes and System V IPC operations. lo - login_logout - Audit &man.login.1; and &man.logout.1; events occurring on the system. na - non attributable - Audit non-attributable events. no - invalid class - Match no audit events. nt - network - Audit events related to network actions, such as &man.connect.2; and &man.accept.2;. ot - other - Audit miscellaneous events. pc - process - Audit process operations, such as &man.exec.3; and &man.exit.3;. These audit event classes may be customized by modifying - the audit_class and - audit_event configuration files. + the audit_class and audit_ + event configuration files. Each audit class in the list is combined with a prefix indicating whether successful/failed operations are matched, and whether the entry is adding or removing matching for the class and type. (none) Audit both successful and failed instances of the event. + Audit successful events in this class. - Audit failed events in this class. ^ Audit neither successful nor failed events in this class. ^+ Do not audit successful events in this class. ^- Do not audit failed events in this class. The following example selection string selects both successful and failed login/logout events, but only successful execution events: lo,+ex Configuration Files In most cases, administrators will need to modify only two - files when configuring the audit system: - audit_control and - audit_user. The first controls - system-wide audit properties and policies; the second may be - used to fine-tune auditing by user. + files when configuring the audit system: audit_ + control and audit_user. + The first controls system-wide audit properties and policies; + the second may be used to fine-tune auditing by user. The <filename>audit_control</filename> File - The audit_control file specifies a - number of defaults for the audit subsystem. Viewing the - contents of this file, we see the following: + A number of defaults for the audit subsystem are + specified in audit_control: dir:/var/audit flags:lo minfree:20 naflags:lo policy:cnt filesz:0 - The option is used to set one or + The entry is used to set one or more directories where audit logs will be stored. If more than one directory entry appears, they will be used in order as they fill. It is common to configure audit so that audit logs are stored on a dedicated file system, in order to prevent interference between the audit subsystem and other subsystems if the file system fills. The field sets the system-wide default preselection mask for attributable events. In the example above, successful and failed login and logout events are audited for all users. - The option defines the minimum + The entry defines the minimum percentage of free space for the file system where the audit trail is stored. When this threshold is exceeded, a warning will be generated. The above example sets the minimum free space to twenty percent. - The option specifies audit - classes to be audited for non-attributed events, such as the - login process and system daemons. + The entry specifies audit classes + to be audited for non-attributed events, such as the login + process and system daemons. - The option specifies a + The entry specifies a comma-separated list of policy flags controlling various aspects of audit behavior. The default cnt flag indicates that the system should continue running despite an auditing failure (this flag is highly recommended). Another commonly used flag is argv, which causes command line arguments to the &man.execve.2; system call to be audited as part of command execution. - The option specifies the maximum + The entry specifies the maximum size in bytes to allow an audit trail file to grow to before automatically terminating and rotating the trail file. The default, 0, disables automatic log rotation. If the requested file size is non-zero and below the minimum 512k, it will be ignored and a log message will be generated. The <filename>audit_user</filename> File - The audit_user file permits the - administrator to specify further audit requirements for - specific users. Each line configures auditing for a user - via two fields: the first is the - alwaysaudit field, which specifies a set - of events that should always be audited for the user, and - the second is the neveraudit field, which - specifies a set of events that should never be audited for - the user. + The administrator can specify further audit requirements + for specific users in audit_user. + Each line configures auditing for a user via two fields: + the first is the alwaysaudit field, + which specifies a set of events that should always be + audited for the user, and the second is the + neveraudit field, which specifies a set + of events that should never be audited for the user. The following example audit_user - file audits login/logout events and successful command - execution for the root user, and audits - file creation and successful command execution for the - www user. If used with the example - audit_control file above, the + audits login/logout events and successful command + execution for root, and audits + file creation and successful command execution for + www. If used with the above example + audit_control, the lo entry for root is redundant, and login/logout events will also be audited for - the www user. + www. root:lo,+ex:no www:fc,+ex:no Administering the Audit Subsystem Viewing Audit Trails Audit trails are stored in the BSM binary format, so tools must be used to modify or convert to text. The &man.praudit.1; command converts trail files to a simple text format; the &man.auditreduce.1; command may be used to reduce the audit trail file for analysis, archiving, or printing - purposes. auditreduce supports a variety - of selection parameters, including event type, event class, + purposes. A variety of selection parameters are supported by + &man.auditreduce.1;, including event type, event class, user, date or time of the event, and the file path or object acted on. - For example, the praudit utility will - dump the entire contents of a specified audit log in plain - text: + For example, &man.praudit.1; will dump the entire + contents of a specified audit log in plain text: &prompt.root; praudit /var/audit/AUDITFILE Where AUDITFILE is the audit log to dump. Audit trails consist of a series of audit records made up - of tokens, which praudit prints - sequentially one per line. Each token is of a specific type, - such as header holding an audit record - header, or path holding a file path from a - name lookup. The following is an example of an + of tokens, which &man.praudit.1; prints sequentially one per + line. Each token is of a specific type, such as + header holding an audit record header, or + path holding a file path from a name + lookup. The following is an example of an execve event: header,133,10,execve(2),0,Mon Sep 25 15:58:03 2006, + 384 msec exec arg,finger,doug path,/usr/bin/finger attribute,555,root,wheel,90,24918,104944 subject,robert,root,wheel,root,wheel,38439,38032,42086,128.232.9.100 return,success,0 trailer,133 This audit represents a successful execve call, in which the command finger doug has been run. The arguments token contains both the processed command line presented by the shell to the kernel. The path token holds the path to the executable as looked up by the kernel. The attribute token describes the binary, and in particular, includes the file mode which can be used to determine if the application was setuid. The subject token describes the subject process, and stores in sequence the audit user ID, effective user ID and group ID, real user ID and group ID, process ID, session ID, port ID, and login address. Notice that the audit user ID and real user ID differ: the user robert has switched to the root account before running this command, but it is audited using the original authenticated user. Finally, the return token indicates the successful execution, and the trailer concludes the record. - praudit also supports - an XML output format, which can be selected using the - argument. + XML output format is also supported by + &man.praudit.1;, and can be selected using + . Reducing Audit Trails Since audit logs may be very large, an administrator will likely want to select a subset of records for using, such as records associated with a specific user: &prompt.root; auditreduce -u trhodes /var/audit/AUDITFILE | praudit - This will select all audit records produced for the user - trhodes stored in the - AUDITFILE - file. + This will select all audit records produced for + trhodes stored in + AUDITFILE. Delegating Audit Review Rights Members of the audit group are - given permission to read audit trails in - /var/audit; by default, this group is - empty, so only the root user may read - audit trails. Users may be added to the + given permission to read audit trails in /var/audit; by default, this + group is empty, so only the root user + may read audit trails. Users may be added to the audit group in order to delegate audit review rights to the user. As the ability to track audit log contents provides significant insight into the behavior of users and processes, it is recommended that the delegation of audit review rights be performed with caution. Live Monitoring Using Audit Pipes Audit pipes are cloning pseudo-devices in the device file system which allow applications to tap the live audit record stream. This is primarily of interest to authors of intrusion detection and system monitoring applications. However, for the administrator the audit pipe device is a convenient way to allow live monitoring without running into problems with audit trail file ownership or log rotation interrupting the event stream. To track the live audit event stream, use the following command line: &prompt.root; praudit /dev/auditpipe By default, audit pipe device nodes are accessible only to the root user. To make them accessible to the members of the audit group, add a devfs rule to devfs.rules: add path 'auditpipe*' mode 0440 group audit See &man.devfs.rules.5; for more information on configuring the devfs file system. It is easy to produce audit event feedback cycles, in which the viewing of each audit event results in the generation of more audit events. For example, if all network I/O is audited, and &man.praudit.1; is run from an SSH session, then a continuous stream of audit events will be generated at a high rate, as each event being printed will generate another event. It is advisable to run - praudit on an audit pipe device from - sessions without fine-grained I/O auditing in order to avoid - this happening. + &man.praudit.1; on an audit pipe device from sessions + without fine-grained I/O auditing in order to avoid this + happening. Rotating Audit Trail Files Audit trails are written to only by the kernel, and - managed only by the audit daemon, - auditd. Administrators should not - attempt to use &man.newsyslog.conf.5; or other tools to - directly rotate audit logs. Instead, the - audit management tool may be used to shut - down auditing, reconfigure the audit system, and perform log - rotation. The following command causes the audit daemon to - create a new audit log and signal the kernel to switch to - using the new log. The old log will be terminated and - renamed, at which point it may then be manipulated by the - administrator. + managed only by the audit daemon, &man.auditd.8;. + Administrators should not attempt to use + &man.newsyslog.conf.5; or other tools to directly rotate + audit logs. Instead, the &man.audit.8; management tool may + be used to shut down auditing, reconfigure the audit system, + and perform log rotation. The following command causes the + audit daemon to create a new audit log and signal the kernel + to switch to using the new log. The old log will be + terminated and renamed, at which point it may then be + manipulated by the administrator. &prompt.root; audit -n - If the auditd daemon is not - currently running, this command will fail and an error - message will be produced. + If &man.auditd.8; is not currently running, this + command will fail and an error message will be + produced. Adding the following line to /etc/crontab will force the rotation every twelve hours from &man.cron.8;: 0 */12 * * * root /usr/sbin/audit -n - The change will take effect once you have saved the - new /etc/crontab. + The change will take effect once you have saved the new + /etc/crontab. Automatic rotation of the audit trail file based on file - size is possible via the option in + size is possible using in &man.audit.control.5;, and is described in the configuration files section of this chapter. Compressing Audit Trails As audit trail files can become very large, it is often desirable to compress or otherwise archive trails once they have been closed by the audit daemon. The audit_warn script can be used to perform customized operations for a variety of audit-related events, including the clean termination of audit trails when they are rotated. For example, the following may be added to the audit_warn script to compress audit trails on close: # # Compress audit trail files on close. # if [ "$1" = closefile ]; then gzip -9 $2 fi Other archiving activities might include copying trail files to a centralized server, deleting old trail files, or reducing the audit trail to remove unneeded records. The script will be run only when audit trail files are cleanly terminated, so will not be run on trails left unterminated following an improper shutdown. diff --git a/en_US.ISO8859-1/books/handbook/basics/chapter.xml b/en_US.ISO8859-1/books/handbook/basics/chapter.xml index 3a5544e5ed..d9dd5a98eb 100644 --- a/en_US.ISO8859-1/books/handbook/basics/chapter.xml +++ b/en_US.ISO8859-1/books/handbook/basics/chapter.xml @@ -1,2651 +1,2658 @@ Chris Shumway Rewritten by UNIX Basics Synopsis This chapter covers the basic commands and functionality of the &os; operating system. Much of this material is relevant for any &unix;-like operating system. New &os; users are encouraged to read through this chapter carefully. After reading this chapter, you will know: How to use the virtual consoles of &os;. How &unix; file permissions and &os; file flags work. The default &os; file system layout. The &os; disk organization. How to mount and unmount file systems. What processes, daemons, and signals are. - What a shell is, and how to change your default login + What a shell is, and how to change the default login environment. How to use basic text editors. What devices and device nodes are. What binary format is used under &os;. How to read manual pages for more information. Virtual Consoles and Terminals virtual consoles terminals &os; can be used in various ways. One of them is typing commands to a text terminal. A lot of the flexibility and power - of a &unix; operating system is readily available at your hands - when using &os; this way. This section describes what + of a &unix; operating system is readily available when using + &os; this way. This section describes what terminals and consoles are, and - how you can use them in &os;. + how to use them in &os;. The Console console Unless &os; has been configured to automatically start a graphical environment during startup, the system will boot into a command line login prompt, as seen in this example: FreeBSD/amd64 (pc3.example.org) (ttyv0) login: The first line contains some information about the system. The amd64 indicates that the system in this example is running a 64-bit version of &os;. The hostname is pc3.example.org, and ttyv0 indicates that this is the system console. The second line is the login prompt. The next section describes how to log into &os; at this prompt. Logging into &os; &os; is a multiuser, multiprocessing system. This is the formal description that is usually given to a system that can be used by many different people, who simultaneously run a lot of programs on a single machine. Every multiuser system needs some way to distinguish one user from the rest. In &os; (and all the &unix;-like operating systems), this is accomplished by requiring that every user must log into the system before being able to run programs. Every user has a unique name (the username) and a personal, secret key (the password). &os; will ask for these two before allowing a user to run any programs. startup scripts When a &os; system boots, startup scripts are automatically executed in order to prepare the system and to start any services which have been configured to start at system boot. Once the system finishes running its startup scripts, it will present a login prompt: login: - Type the username that was configured during system installation and - press Enter. Then enter the password - associated with the username and press Enter. - The password is not echoed for security + Type the username that was configured during system + installation, as described in , and press + Enter. Then enter the password associated + with the username and press Enter. The + password is not echoed for security reasons. - Once the correct password is input, the message of - the day (MOTD) will be displayed followed + Once the correct password is input, the message of the + day (MOTD) will be displayed followed by a command prompt (a #, $, or % character). You are now logged into the &os; console and ready to try the available commands. Virtual Consoles &os; can be configured to provide many virtual consoles for inputting commands. Each virtual console has its own login prompt and output channel, and &os; takes care of - properly redirecting keyboard input and monitor output as you - switch between virtual consoles. + properly redirecting keyboard input and monitor output as + switching occurs between virtual consoles. Special key combinations have been reserved by &os; for switching consoles. Refer to &man.syscons.4;, &man.atkbd.4;, &man.vidcontrol.1; and &man.kbdcontrol.1; for a more technical description of the &os; console and its keyboard drivers.. Use AltF1, AltF2, through AltF8 to switch to a different virtual console in &os;. When switching from one console to the next, &os; takes care of saving and restoring the screen output. The result is an illusion of having multiple virtual screens and keyboards that can be used to type commands for &os; to run. The programs that are launched in one virtual console do not stop running when that console is not visible because the user has switched to a different virtual console. The <filename>/etc/ttys</filename> File By default, &os; is configured to start eight virtual consoles. The configuration can be customized to start more or fewer virtual consoles. To change the number of and the settings of the virtual consoles, edit /etc/ttys. Each uncommented line in /etc/ttys (lines that do not start with a # character) contains settings for a single terminal or virtual console. The default version configures nine virtual consoles, and enables eight of them. They are the lines that start with ttyv: # name getty type status comments # ttyv0 "/usr/libexec/getty Pc" cons25 on secure # Virtual terminals ttyv1 "/usr/libexec/getty Pc" cons25 on secure ttyv2 "/usr/libexec/getty Pc" cons25 on secure ttyv3 "/usr/libexec/getty Pc" cons25 on secure ttyv4 "/usr/libexec/getty Pc" cons25 on secure ttyv5 "/usr/libexec/getty Pc" cons25 on secure ttyv6 "/usr/libexec/getty Pc" cons25 on secure ttyv7 "/usr/libexec/getty Pc" cons25 on secure ttyv8 "/usr/X11R6/bin/xdm -nodaemon" xterm off secure For a detailed description of every column in this file and the available options for the virtual consoles, refer to &man.ttys.5;. Single User Mode Console A detailed description of single user mode - can be found here. - There is only one console when &os; is in single user mode as - no other virtual consoles are available in this mode. The - settings for single user mode are found in this section of + can be found in . There is + only one console when &os; is in single user mode as no other + virtual consoles are available in this mode. The settings + for single user mode are found in this section of /etc/ttys: # name getty type status comments # # If console is marked "insecure", then init will ask for the root password # when going to single-user mode. console none unknown off secure As the comments above the console line indicate, editing secure to insecure will prompt for the root password when booting into single user mode. The default setting enters single user mode without prompting for a password. Be careful when changing this setting to - insecure. If you ever - forget the root password, booting into - single user mode is still possible, but may be difficult for - someone who is not comfortable with the &os; booting - process. + insecure. If the + root password is forgotten, booting + into single user mode is still possible, but may be + difficult for someone who is not comfortable with the &os; + booting process. Changing Console Video Modes The &os; console default video mode may be adjusted to 1024x768, 1280x1024, or any other size supported by the graphics chip and monitor. To use a different video mode load the VESA module: &prompt.root; kldload vesa To determine which video modes are supported by the hardware, use &man.vidcontrol.1;. To get a list of supported video modes issue the following: &prompt.root; vidcontrol -i mode The output of this command lists the video modes that are supported by the hardware. To select a new video mode, specify the mode using &man.vidcontrol.1; as the root user: &prompt.root; vidcontrol MODE_279 If the new video mode is acceptable, it can be permanently set on boot by adding it to /etc/rc.conf: allscreens_flags="MODE_279" Permissions UNIX &os;, being a direct descendant of BSD &unix;, is based on several key &unix; concepts. The first and most pronounced is that &os; is a multi-user operating system that can handle several users working simultaneously on completely unrelated tasks. The system is responsible for properly sharing and managing requests for hardware devices, peripherals, memory, and CPU time fairly to each user. + Much more information about user accounts is in the chapter + about accounts. It is important to + understand that each person (user) who uses the computer should be + given their own username and password. The system keeps track + of the people using the computer based on this username. Since + it is often the case that several people are working on the same + project &unix; also provides groups. Several users can be placed + in the same group. + Because the system is capable of supporting multiple users, everything the system manages has a set of permissions governing who can read, write, and execute the resource. These permissions are stored as three octets broken into three pieces, one for the owner of the file, one for the group that the file belongs to, and one for everyone else. This numerical representation works like this: This section will discuss the traditional &unix; permissions. For finer grained file system access control, see the File System Access Control Lists section. permissions file permissions Value Permission Directory Listing 0 No read, no write, no execute --- 1 No read, no write, execute --x 2 No read, write, no execute -w- 3 No read, write, execute -wx 4 Read, no write, no execute r-- 5 Read, no write, execute r-x 6 Read, write, no execute rw- 7 Read, write, execute rwx - ls + &man.ls.1; directories Use the argument to &man.ls.1; to view a long directory listing that includes a column of information about a file's permissions for the owner, group, and everyone else. For example, a ls -l in an arbitrary directory may show: &prompt.user; ls -l total 530 -rw-r--r-- 1 root wheel 512 Sep 5 12:31 myfile -rw-r--r-- 1 root wheel 512 Sep 5 12:31 otherfile -rw-r--r-- 1 root wheel 7680 Sep 5 12:31 email.txt The first (leftmost) character in the first column indicates whether this file is a regular file, a directory, a special character device, a socket, or any other special pseudo-file device. In this example, the - indicates a regular file. The next three characters, rw- in this example, give the permissions for the owner of the file. The next three characters, r--, give the permissions for the group that the file belongs to. The final three characters, r--, give the permissions for the rest of the world. A dash means that the permission is turned off. In this example, the permissions are set so the owner can read and write to the file, the group can read the file, and the rest of the world can only read the file. According to the table above, the permissions for this file would be 644, where each digit represents the three parts of the file's permission. How does the system control permissions on devices? &os; treats most hardware devices as a file that programs can open, read, and write data to. These special device files are stored in /dev/. Directories are also treated as files. They have read, write, and execute permissions. The executable bit for a directory has a slightly different meaning than that of files. When a directory is marked executable, it means it is possible - to change into that directory using - cd. This also means that it is - possible to access the files within that directory, subject to - the permissions on the files themselves. + to change into that directory using &man.cd.1;. This also + means that it is possible to access the files within that + directory, subject to the permissions on the files + themselves. In order to perform a directory listing, the read permission must be set on the directory. In order to delete a file that one knows the name of, it is necessary to have write and execute permissions to the directory containing the file. There are more permission bits, but they are primarily used in special circumstances such as setuid binaries and sticky directories. For more information on file permissions and how to set them, refer to &man.chmod.1;. Tom Rhodes Contributed by Symbolic Permissions permissions symbolic Symbolic permissions use characters instead of octal values to assign permissions to files or directories. Symbolic permissions use the syntax of (who) (action) (permissions), where the following values are available: Option Letter Represents (who) u User (who) g Group owner (who) o Other (who) a All (world) (action) + Adding permissions (action) - Removing permissions (action) = Explicitly set permissions (permissions) r Read (permissions) w Write (permissions) x Execute (permissions) t Sticky bit (permissions) s Set UID or GID These values are used with &man.chmod.1;, but with letters instead of numbers. For example, the following command would block other users from accessing FILE: &prompt.user; chmod go= FILE A comma separated list can be provided when more than one set of changes to a file must be made. For example, the following command removes the group and world write permission on FILE, and adds the execute permissions for everyone: &prompt.user; chmod go-w,a+x FILE Tom Rhodes Contributed by &os; File Flags In addition to file permissions, &os; supports the use of file flags. These flags add an additional - level of security and control over files, but not - directories. With file flags, even - root can be prevented from removing or - altering files. + level of security and control over files, but not directories. + With file flags, even root can be + prevented from removing or altering files. File flags are modified using &man.chflags.1;. For example, to enable the system undeletable flag on the file file1, issue the following command: &prompt.root; chflags sunlink file1 To disable the system undeletable flag, put a no in front of the : &prompt.root; chflags nosunlink file1 To view the flags of a file, use with &man.ls.1;: &prompt.root; ls -lo file1 -rw-r--r-- 1 trhodes trhodes sunlnk 0 Mar 1 05:54 file1 Several file flags may only be added or removed by the root user. In other cases, the file owner may set its file flags. Refer to &man.chflags.1; and &man.chflags.2; for more information. Tom Rhodes Contributed by The <literal>setuid</literal>, <literal>setgid</literal>, and <literal>sticky</literal> Permissions Other than the permissions already discussed, there are three other specific settings that all administrators should know about. They are the setuid, setgid, and sticky permissions. These settings are important for some &unix; operations as they provide functionality not normally granted to normal users. To understand them, the difference between the real user ID and effective user ID must be noted. The real user ID is the UID who owns or starts the process. The effective UID is the user ID the process runs as. As an example, &man.passwd.1; runs with the real user ID when a user changes their password. However, in order to update the password database, the command runs as the effective ID of the root user. This allows users to change their passwords without seeing a Permission Denied error. The setuid permission may be set by prefixing a permission set with the number four (4) as shown in the following example: &prompt.root; chmod 4755 suidexample.sh The permissions on suidexample.sh now look like the following: -rwsr-xr-x 1 trhodes trhodes 63 Aug 29 06:36 suidexample.sh Note that a s is now part of the permission set designated for the file owner, replacing the executable bit. This allows utilities which need elevated - permissions, such as passwd. + permissions, such as &man.passwd.1;. The nosuid &man.mount.8; option will cause such binaries to silently fail without alerting the user. That option is not completely reliable as a nosuid wrapper may be able to circumvent it. To view this in real time, open two terminals. On - one, start the passwd process as a normal - user. While it waits for a new password, check the process + one, type passwd as a normal user. + While it waits for a new password, check the process table and look at the user information for - passwd: + &man.passwd.1;: In terminal A: Changing local password for trhodes Old Password: In terminal B: &prompt.root; ps aux | grep passwd trhodes 5232 0.0 0.2 3420 1608 0 R+ 2:10AM 0:00.00 grep passwd root 5211 0.0 0.2 3620 1724 2 I+ 2:09AM 0:00.01 passwd - As stated above, the passwd is run - by a normal user, but is using the effective - UID of root. + Although &man.passwd.1; is run as a normal user, it is + using the effective UID of + root. The setgid permission performs the same function as the setuid permission; except that it alters the group settings. When an application or utility executes with this setting, it will be granted the permissions based on the group that owns the file, not the user who started the process. To set the setgid permission on a - file, provide chmod with a leading two - (2): + file, provide &man.chmod.1; with a leading two (2): &prompt.root; chmod 2755 sgidexample.sh In the following listing, notice that the s is now in the field designated for the group permission settings: -rwxr-sr-x 1 trhodes trhodes 44 Aug 31 01:49 sgidexample.sh In these examples, even though the shell script in question is an executable file, it will not run with a different EUID or effective user ID. This is because shell scripts may not access the &man.setuid.2; system calls. The setuid and setgid permission bits may lower system security, by allowing for elevated permissions. The third special permission, the sticky bit, can strengthen the security of a system. When the sticky bit is set on a directory, it allows file deletion only by the file owner. This is useful to prevent file deletion in public directories, such as /tmp, by users who do not own the file. To utilize this permission, prefix the permission set with a one (1): &prompt.root; chmod 1777 /tmp The sticky bit permission will display as a t at the very end of the permission set: &prompt.root; ls -al / | grep tmp drwxrwxrwt 10 root wheel 512 Aug 31 01:49 tmp Directory Structure directory hierarchy The &os; directory hierarchy is fundamental to obtaining an overall understanding of the system. The most important directory is root or, /. This directory is the first one mounted at boot time and it contains the base system necessary to prepare the operating system for multi-user operation. The root directory also contains mount points for other file systems that are mounted during the transition to multi-user operation. A mount point is a directory where additional file systems can be grafted onto a parent file system (usually the root file system). This is further described in . Standard mount points include /usr/, /var/, /tmp/, /mnt/, and /cdrom/. These directories are usually referenced to entries in /etc/fstab. This file is a table of various file systems and mount points and is read by the system. Most of the file systems in /etc/fstab are mounted automatically at boot time from the script &man.rc.8; unless their entry includes . Details can be found in . A complete description of the file system hierarchy is available in &man.hier.7;. The following table provides a brief overview of the most common directories. Directory Description / Root directory of the file system. /bin/ User utilities fundamental to both single-user and multi-user environments. /boot/ Programs and configuration files used during operating system bootstrap. /boot/defaults/ Default boot configuration files. Refer to &man.loader.conf.5; for details. /dev/ Device nodes. Refer to &man.intro.4; for details. /etc/ System configuration files and scripts. /etc/defaults/ Default system configuration files. Refer to &man.rc.8; for details. /etc/mail/ Configuration files for mail transport agents such as &man.sendmail.8;. /etc/namedb/ - named configuration files. - Refer to &man.named.8; for details. + &man.named.8; configuration files. /etc/periodic/ Scripts that run daily, weekly, and monthly, via &man.cron.8;. Refer to &man.periodic.8; for details. /etc/ppp/ - ppp configuration files as - described in &man.ppp.8;. + &man.ppp.8; configuration files. /mnt/ Empty directory commonly used by system administrators as a temporary mount point. /proc/ Process file system. Refer to &man.procfs.5;, &man.mount.procfs.8; for details. /rescue/ Statically linked programs for emergency recovery as described in &man.rescue.8;. /root/ Home directory for the root account. /sbin/ System programs and administration utilities fundamental to both single-user and multi-user environments. /tmp/ Temporary files which are usually not preserved across a system reboot. A memory-based file system is often mounted at /tmp. This can be automated using the tmpmfs-related variables of &man.rc.conf.5; or with an entry in /etc/fstab; refer to &man.mdmfs.8; for details. /usr/ The majority of user utilities and applications. /usr/bin/ Common utilities, programming tools, and applications. /usr/include/ Standard C include files. /usr/lib/ Archive libraries. /usr/libdata/ Miscellaneous utility data files. /usr/libexec/ System daemons and system utilities executed by other programs. /usr/local/ Local executables and libraries. Also used as - the default destination for the &os; ports - framework. Within - /usr/local, the + the default destination for the &os; ports framework. + Within /usr/local, the general layout sketched out by &man.hier.7; for /usr should be used. Exceptions are the man directory, which is - directly under - /usr/local - rather than under - /usr/local/share, - and the ports documentation is in - share/doc/port. + directly under /usr/local + rather than under /usr/local/share, + and the ports documentation is in share/doc/port. /usr/obj/ Architecture-specific target tree produced by - building the - /usr/src + building the /usr/src tree. /usr/ports/ The &os; Ports Collection (optional). /usr/sbin/ System daemons and system utilities executed by users. /usr/share/ Architecture-independent files. /usr/src/ BSD and/or local source files. /var/ Multi-purpose log, temporary, transient, and spool files. A memory-based file system is sometimes mounted at /var. This can be automated using the varmfs-related variables in &man.rc.conf.5; or with an entry in /etc/fstab; refer to &man.mdmfs.8; for details. /var/log/ Miscellaneous system log files. /var/mail/ User mailbox files. /var/spool/ Miscellaneous printer and mail system spooling directories. /var/tmp/ Temporary files which are usually preserved - across a system reboot, unless - /var is a + across a system reboot, unless /var is a memory-based file system. /var/yp/ NIS maps. Disk Organization The smallest unit of organization that &os; uses to find files is the filename. Filenames are case-sensitive, which means that readme.txt and README.TXT are two separate files. &os; does not use the extension of a file to determine whether the file is a program, document, or some other form of data. Files are stored in directories. A directory may contain no files, or it may contain many hundreds of files. A directory - can also contain other directories, allowing you to build up a - hierarchy of directories within one another in order to organize + can also contain other directories, allowing a hierarchy of + directories within one another in order to organize data. Files and directories are referenced by giving the file or directory name, followed by a forward slash, /, followed by any other directory names that - are necessary. For example, if the directory - foo contains a directory + are necessary. For example, if the directory foo contains a directory bar which contains the file readme.txt, the full name, or path, to the file is foo/bar/readme.txt. Note that this is - different from &windows; which uses - \ to separate file and directory - names. &os; does not use drive letters, or other drive names in - the path. For example, you would not type - c:/foo/bar/readme.txt on &os;. + different from &windows; which uses \ to + separate file and directory names. &os; does not use drive + letters, or other drive names in the path. For example, one + would not type c:/foo/bar/readme.txt on + &os;. Directories and files are stored in a file system. Each file system contains exactly one directory at the very top level, called the root directory for that - file system. This root directory can contain other - directories. One file system is designated the - root file system or /. - Every other file system is mounted under - the root file system. No matter how many disks you have on your - &os; system, every directory appears to be part of the same - disk. - - Suppose you have three file systems, called - A, B, and - C. Each file system has one root directory, - which contains two other directories, called - A1, A2 (and likewise - B1, B2 and + file system. This root directory can contain other directories. + One file system is designated the root file + system or /. Every other file + system is mounted under the root file + system. No matter how many disks are on the &os; system, every + directory appears to be part of the same disk. + + Consider three file systems, called A, + B, and C. Each file + system has one root directory, which contains two other + directories, called A1, A2 + (and likewise B1, B2 and C1, C2). - Call A the root file system. If you used - ls to view the contents of this directory you - would see two subdirectories, A1 and + Call A the root file system. If + &man.ls.1; is used to view the contents of this directory, + it will show two subdirectories, A1 and A2. The directory tree looks like this: / | +--- A1 | `--- A2 A file system must be mounted on to a directory in another - file system. When mounting file system - B on to the directory A1, - the root directory of B replaces - A1, and the directories in - B appear accordingly: + file system. When mounting file system B + on to the directory A1, the root directory + of B replaces A1, and + the directories in B appear + accordingly: / | +--- A1 | | | +--- B1 | | | `--- B2 | `--- A2 Any files that are in the B1 or B2 directories can be reached with the path - /A1/B1 or - /A1/B2 as - necessary. Any files that were in - /A1 have + /A1/B1 or /A1/B2 as necessary. Any files + that were in /A1 have been temporarily hidden. They will reappear if B is unmounted from A. If B had been mounted on A2 then the diagram would look like this: / | +--- A1 | `--- A2 | +--- B1 | `--- B2 and the paths would be - /A2/B1 and - /A2/B2 - respectively. + /A2/B1 and /A2/B2 respectively. File systems can be mounted on top of one another. Continuing the last example, the C file system could be mounted on top of the B1 directory in the B file system, leading to this arrangement: / | +--- A1 | `--- A2 | +--- B1 | | | +--- C1 | | | `--- C2 | `--- B2 Or C could be mounted directly on to the A file system, under the A1 directory: / | +--- A1 | | | +--- C1 | | | `--- C2 | `--- A2 | +--- B1 | `--- B2 - Typically you create file systems when installing &os; - and decide where to mount them, and then never change them - unless you add a new disk. - It is entirely possible to have one large root file system, and not need to create any others. There are some drawbacks to this approach, and one advantage. Benefits of Multiple File Systems Different file systems can have different mount options. For example, the root file system can be mounted read-only, making it impossible for users to inadvertently delete or edit a critical file. - Separating user-writable file systems, such as - /home, from other - file systems allows them to be mounted + Separating user-writable file systems, such as /home, from other file + systems allows them to be mounted nosuid. This option prevents the suid/guid bits on executables stored on the file system from taking effect, possibly improving security. &os; automatically optimizes the layout of files on a file system, depending on how the file system is being used. So a file system that contains many small files that are written frequently will have a different optimization to one that contains fewer, larger files. By having one big file system this optimization breaks down. - &os;'s file systems are very robust should you lose - power. However, a power loss at a critical point could - still damage the structure of the file system. By splitting + &os;'s file systems are robust if power is lost. + However, a power loss at a critical point could still + damage the structure of the file system. By splitting data over multiple file systems it is more likely that the system will still come up, making it easier to restore from backup as necessary. Benefit of a Single File System File systems are a fixed size. If you create a file system when you install &os; and give it a specific size, you may later discover that you need to make the partition bigger. This is not easily accomplished without backing up, recreating the file system with the new size, and then restoring the backed up data. &os; features the &man.growfs.8; command, which makes it possible to increase the size of file system on the fly, removing this limitation. File systems are contained in partitions. This does not have the same meaning as the common usage of the term partition (for example, &ms-dos; partition), because of &os;'s &unix; heritage. Each partition is identified by a letter from a through to h. Each partition can contain only one file system, which means that file systems are often described by either their typical mount point in the file system hierarchy, or the letter of the partition they are contained in. &os; also uses disk space for swap space to provide virtual memory. This allows your computer to behave as though it has much more memory than it actually does. When &os; runs out of memory, it moves some of the data that is not currently being used to the swap space, and moves it back in (moving something else out) when it needs it. Some partitions have certain conventions associated with them. Partition Convention a Normally contains the root file system. b Normally contains swap space. c Normally the same size as the enclosing slice. This allows utilities that need to work on the entire slice, such as a bad block scanner, to work on the - c partition. You would not normally - create a file system on this partition. + c partition. A file system would not + normally be + created on this partition. d Partition d used to have a special meaning associated with it, although that is now gone and d may work as any normal partition. Disks in &os; are divided into slices, referred to in &windows; as partitions, which are numbered from 1 to 4. These are then then divided into partitions, which contain file systems, and are labeled using letters. slices partitions dangerously dedicated Slice numbers follow the device name, prefixed with an s, starting at 1. So da0s1 is the first slice on the first SCSI drive. There can only be four physical slices on - a disk, but you can have logical slices inside physical slices + a disk, but there can be logical slices inside physical slices of the appropriate type. These extended slices are numbered starting at 5, so ad0s5 is the first extended slice on the first IDE disk. These devices are used by file systems that expect to occupy a slice. Slices, dangerously dedicated physical drives, and other drives contain partitions, which are represented as letters from a to h. This letter is appended to the device name, so - da0a is the a partition on - the first da drive, which is dangerously - dedicated. ad1s3e is - the fifth partition in the third slice of the second IDE disk - drive. + da0a is the + a partition on the first + da drive, which is dangerously + dedicated. ad1s3e + is the fifth partition in the third slice of the second IDE + disk drive. Finally, each disk on the system is identified. A disk name starts with a code that indicates the type of disk, and then a number, indicating which disk it is. Unlike slices, disk - numbering starts at 0. Common codes that you will see are - listed in . + numbering starts at 0. Common codes are listed in . When referring to a partition, include the disk name, s, the slice number, and then the partition letter. Examples are shown in . shows a conceptual model of a disk layout. When installing &os;, configure the disk slices, create partitions within the slice to be used for &os;, create a file system or swap space in each partition, and decide where each file system will be mounted. Disk Device Codes Code Meaning ad ATAPI (IDE) disk da SCSI direct access disk acd ATAPI (IDE) CDROM cd SCSI CDROM fd Floppy disk
Sample Disk, Slice, and Partition Names Name Meaning ad0s1a The first partition (a) on the first slice (s1) on the first IDE disk (ad0). da1s2e The fifth partition (e) on the second slice (s2) on the second SCSI disk (da1). Conceptual Model of a Disk This diagram shows &os;'s view of the first IDE disk attached to the system. Assume that the disk is 4 GB in size, and contains two 2 GB slices (&ms-dos; partitions). The first slice contains a &ms-dos; disk, C:, and the second slice contains a &os; installation. This example &os; installation has three data partitions, and a swap partition. The three partitions will each hold a file system. Partition a will be used for the root file system, e for the /var/ directory hierarchy, and f for the /usr/ directory hierarchy. .-----------------. --. | | | | DOS / Windows | | : : > First slice, ad0s1 : : | | | | :=================: ==: --. | | | Partition a, mounted as / | | | > referred to as ad0s2a | | | | | :-----------------: ==: | | | | Partition b, used as swap | | | > referred to as ad0s2b | | | | | :-----------------: ==: | Partition c, no | | | Partition e, used as /var > file system, all | | > referred to as ad0s2e | of FreeBSD slice, | | | | ad0s2c :-----------------: ==: | | | | | : : | Partition f, used as /usr | : : > referred to as ad0s2f | : : | | | | | | | | --' | `-----------------' --' Mounting and Unmounting File Systems The file system is best visualized as a tree, rooted, as it were, at /. - /dev, - /usr, and the - other directories in the root directory are branches, which may - have their own branches, such as - /usr/local, and so - on. + /dev, /usr, and the other directories + in the root directory are branches, which may have their own + branches, such as /usr/local, and so on. root file system There are various reasons to house some of these directories on separate file systems. /var contains the directories log/, spool/, and various types of temporary files, and as such, may get filled up. Filling up the root file system is not a good idea, so splitting /var from - / is often - favorable. + class="directory">/var from / is often favorable. Another common reason to contain certain directory trees on other file systems is if they are to be housed on separate - physical disks, or are separate virtual disks, such as - Network File System mounts, + physical disks, or are separate virtual disks, such as Network + File System mounts, described in , or CDROM drives. The <filename>fstab</filename> File file systems mounted with fstab - During the boot process, + During the boot process (), file systems listed in /etc/fstab are automatically mounted except for the entries containing . This file contains entries in the following format: device /mount-point fstype options dumpfreq passno device An existing device name as explained in . mount-point An existing directory on which to mount the file system. fstype The file system type to pass to &man.mount.8;. The default &os; file system is ufs. options - Either for read-write - file systems, or for read-only file + Either for read-write file + systems, or for read-only file systems, followed by any other options that may be needed. A common option is for file systems not normally mounted during the boot sequence. Other options are listed in &man.mount.8;. dumpfreq Used by &man.dump.8; to determine which file systems require dumping. If the field is missing, a value of zero is assumed. passno Determines the order in which file systems should be checked. File systems that should be skipped should have their passno set to zero. The root file system needs to be checked before everything else and should have its passno set to one. The other file systems should be set to values greater than one. If more than one file system has the same passno, &man.fsck.8; will attempt to check file systems in parallel if possible. Refer to &man.fstab.5; for more information on the format of /etc/fstab and its options. - The <command>mount</command> Command + Using &man.mount.8; file systems mounting File systems are mounted using &man.mount.8;. The most basic syntax is as follows: &prompt.root; mount device mountpoint This command provides many options which are described in &man.mount.8;, The most commonly used options include: Mount Options Mount all the file systems listed in /etc/fstab, except those marked as noauto, excluded by the flag, or those that are already mounted. Do everything except for the actual mount system call. This option is useful in conjunction with the flag to determine what &man.mount.8; is actually trying to do. Force the mount of an unclean file system (dangerous), or the revocation of write access when downgrading a file system's mount status from read-write to read-only. Mount the file system read-only. This is identical to using . fstype Mount the specified file system type or mount only file systems of the given type, if is included. ufs is the default file system type. Update mount options on the file system. Be verbose. Mount the file system read-write. The following options can be passed to as a comma-separated list: nosuid Do not interpret setuid or setgid flags on the file system. This is also a useful security option. - The <command>umount</command> Command + Using &man.umount.8; file systems unmounting - To unmount a filesystem use &man.umount.8;. This command + To unmount a file system use &man.umount.8;. This command takes one parameter which can be a mountpoint, device name, or . All forms take to force unmounting, and for verbosity. Be warned that is not generally a good idea as it might crash the computer or damage data on the file system. To unmount all mounted file systems, or just the file system types listed after , use or . Note that does not attempt to unmount the root file system. Processes &os; is a multi-tasking operating system. Each program running at any one time is called a process. Every running command starts at least one new process and there are a number of system processes that are run by &os;. Each process is uniquely identified by a number called a - process ID - (PID). Similar to files, each process - has one owner and group, and the owner and group permissions are - used to determine which files and devices the process can open. - Most processes also have a parent process that started them. - For example, the shell is a process, and any command started in - the shell is a process which has the shell as its parent - process. The exception is a special process called - &man.init.8; which is always the first process to start at boot - time and which always has a PID of 1. + process ID (PID). + Similar to files, each process has one owner and group, and + the owner and group permissions are used to determine which + files and devices the process can open. Most processes also + have a parent process that started them. For example, the + shell is a process, and any command started in the shell is a + process which has the shell as its parent process. The + exception is a special process called &man.init.8; which is + always the first process to start at boot time and which always + has a PID of 1. To see the processes on the system, use &man.ps.1; and &man.top.1;. To display a static list of the currently running - processes, their PIDs, how much memory they are using, and the - command they were started with, use ps. To - display all the running processes and update the display every - few seconds so that you can interactively see what the computer - is doing, use top. + processes, their PIDs, how much memory they + are using, and the command they were started with, use + &man.ps.1;. To display all the running processes and update + the display every few seconds in order to interactively see + what the computer is doing, use &man.top.1;. - By default, ps only shows the commands - that are running and owned by the user. For example: + By default, &man.ps.1; only shows the commands that are + running and owned by the user. For example: &prompt.user; ps PID TT STAT TIME COMMAND 298 p0 Ss 0:01.10 tcsh 7078 p0 S 2:40.88 xemacs mdoc.xsl (xemacs-21.1.14) 37393 p0 I 0:03.11 xemacs freebsd.dsl (xemacs-21.1.14) 72210 p0 R+ 0:00.00 ps 390 p1 Is 0:01.14 tcsh 7059 p2 Is+ 1:36.18 /usr/local/bin/mutt -y 6688 p3 IWs 0:00.00 tcsh 10735 p4 IWs 0:00.00 tcsh 20256 p5 IWs 0:00.00 tcsh 262 v0 IWs 0:00.00 -tcsh (tcsh) 270 v0 IW+ 0:00.00 /bin/sh /usr/X11R6/bin/startx -- -bpp 16 280 v0 IW+ 0:00.00 xinit /home/nik/.xinitrc -- -bpp 16 284 v0 IW 0:00.00 /bin/sh /home/nik/.xinitrc 285 v0 S 0:38.45 /usr/X11R6/bin/sawfish The output from &man.ps.1; is organized into a number of columns. The PID column displays the process - ID. PIDs are assigned starting at 1, go up to 99999, then wrap - around back to the beginning. However, a PID is not reassigned - if it is already in use. The TT column shows - the tty the program is running on and STAT - shows the program's state. TIME is the - amount of time the program has been running on the CPU. This is - usually not the elapsed time since the program was started, as - most programs spend a lot of time waiting for things to happen - before they need to spend time on the CPU. Finally, + ID. PIDs are assigned starting at 1, go up + to 99999, then wrap around back to the beginning. However, a + PID is not reassigned if it is already in + use. The TT column shows the tty the program + is running on and STAT shows the program's + state. TIME is the amount of time the + program has been running on the CPU. This is usually not the + elapsed time since the program was started, as most programs + spend a lot of time waiting for things to happen before they + need to spend time on the CPU. Finally, COMMAND is the command that was used to start the program. &man.ps.1; supports a number of different options to change the information that is displayed. One of the most useful sets is auxww. displays information about all the running processes of all users. displays the username of the process' owner, as well as memory usage. displays information about daemon processes, and causes &man.ps.1; to display the full command line for each process, rather than truncating it once it gets too long to fit on the screen. The output from &man.top.1; is similar. A sample session looks like this: &prompt.user; top last pid: 72257; load averages: 0.13, 0.09, 0.03 up 0+13:38:33 22:39:10 47 processes: 1 running, 46 sleeping CPU states: 12.6% user, 0.0% nice, 7.8% system, 0.0% interrupt, 79.7% idle Mem: 36M Active, 5256K Inact, 13M Wired, 6312K Cache, 15M Buf, 408K Free Swap: 256M Total, 38M Used, 217M Free, 15% Inuse PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND 72257 nik 28 0 1960K 1044K RUN 0:00 14.86% 1.42% top 7078 nik 2 0 15280K 10960K select 2:54 0.88% 0.88% xemacs-21.1.14 281 nik 2 0 18636K 7112K select 5:36 0.73% 0.73% XF86_SVGA 296 nik 2 0 3240K 1644K select 0:12 0.05% 0.05% xterm 175 root 2 0 924K 252K select 1:41 0.00% 0.00% syslogd 7059 nik 2 0 7260K 4644K poll 1:38 0.00% 0.00% mutt ... The output is split into two sections. The header (the - first five lines) shows the PID of the last process to run, the - system load averages (which are a measure of how busy the system - is), the system uptime (time since the last reboot) and the - current time. The other figures in the header relate to how - many processes are running (47 in this case), how much memory - and swap space has been used, and how much time the system is - spending in different CPU states. + first five lines) shows the PID of the last + process to run, the system load averages (which are a measure + of how busy the system is), the system uptime (time since the + last reboot) and the current time. The other figures in the + header relate to how many processes are running (47 in this + case), how much memory and swap space has been used, and how + much time the system is spending in different CPU states. Below the header is a series of columns containing similar - information to the output from &man.ps.1;, such as the PID, - username, amount of CPU time, and the command that started the - process. By default, &man.top.1; also displays the amount of - memory space taken by the process. This is split into two - columns: one for total size and one for resident size. Total - size is how much memory the application has needed and the - resident size is how much it is actually using at the moment. - In this example, mutt has - required almost 8 MB of RAM, but is currently only using - 5 MB. + information to the output from &man.ps.1;, such as the + PID, username, amount of CPU time, and the + command that started the process. By default, &man.top.1; also + displays the amount of memory space taken by the process. + This is split into two columns: one for total size and one for + resident size. Total size is how much memory the application + has needed and the resident size is how much it is actually + using at the moment. In this example, + mutt has required almost 8 MB + of RAM, but is currently only using 5 MB. &man.top.1; automatically updates the display every two seconds. A different interval can be specified with . Daemons, Signals, and Killing Processes When using an editor, it is easy to control the editor and load files because the editor provides facilities to do so, and because the editor is attached to a terminal. Some programs are not designed to be run with continuous user input and disconnect from the terminal at the first opportunity. For example, a web server responds to web requests, rather than user input. Mail servers are another example of this type of application. These programs are known as daemons. The term daemon comes from Greek mythology and represents an entity that is neither good or evil, and which invisibly performs useful tasks. This is why the BSD mascot is the cheerful-looking daemon with sneakers and a pitchfork. There is a convention to name programs that normally run as daemons with a trailing d. BIND is the Berkeley Internet Name - Domain, but the actual program that executes is - named. The Apache - web server program is httpd and the - line printer spooling daemon is lpd. This is - only a naming convention. For example, the main mail daemon for - the Sendmail application is - sendmail, and not - maild. + Domain, but the actual program that executes is &man.named.8;. + The Apache web server program is + httpd and the line printer spooling daemon + is &man.lpd.8;. This is only a naming convention. For example, + the main mail daemon for the Sendmail + application is &man.sendmail.8;, and not + maild. One way to communicate with a daemon, or any running process, is to send a signal using &man.kill.1;. There are a number of different signals; some have a specific meaning while others are described in the application's documentation. A user can only send a signal to a process they own and sending a signal to someone else's process will result in a permission denied error. The exception is the root user, who can send signals to anyone's processes. &os; can also send a signal to a process. If an application is badly written and tries to access memory that it is not supposed to, &os; will send the process the Segmentation Violation signal (SIGSEGV). If an application has used the &man.alarm.3; system call to be alerted after a period of time has elapsed, it will be sent the Alarm signal (SIGALRM). Two signals can be used to stop a process: SIGTERM and SIGKILL. SIGTERM is the polite way to kill a process as the process can read the signal, close any log files it may have open, and attempt to finish what it is doing before shutting down. In some cases, a process may ignore SIGTERM if it is in the middle of some task that can not be interrupted. SIGKILL can not be ignored by a process. This is the I do not care what you are doing, stop right now signal. Sending a SIGKILL to a process will usually stop that process there and then. There are a few tasks that can not be interrupted. For example, if the process is trying to read from a file that is on another computer on the network, and the other computer is unavailable, the process is said to be uninterruptible. Eventually the process will time out, typically after two minutes. As soon as this time out occurs the process will be killed. . Other commonly used signals are SIGHUP, SIGUSR1, and SIGUSR2. These are general purpose signals and different applications will respond differently. For example, after changing a web server's configuration file, the web server needs to be told to re-read its configuration. Restarting httpd would result in a brief outage period on the web server. Instead, send the daemon the SIGHUP signal. Be aware that different daemons will have different behavior, so refer to the documentation for the daemon to determine if SIGHUP will achieve the desired results. Sending a Signal to a Process This example shows how to send a signal to &man.inetd.8;. - The inetd configuration file is - /etc/inetd.conf, and - inetd will re-read this configuration file - when it is sent a SIGHUP. + The &man.inetd.8; configuration file is + /etc/inetd.conf, and &man.inetd.8; will + re-read this configuration file when it is sent a + SIGHUP. - Find the PID of the process you want to send the signal - to using &man.pgrep.1;. In this example, the PID for - &man.inetd.8; is 198: + Find the PID of the process to send + the signal to using &man.pgrep.1;. In this example, the + PID for &man.inetd.8; is 198: &prompt.user; pgrep -l inetd 198 inetd -wW Use &man.kill.1; to send the signal. Because &man.inetd.8; is owned by root, use &man.su.1; to become root first. &prompt.user; su Password: &prompt.root; /bin/kill -s HUP 198 Like most &unix; commands, &man.kill.1; will not print - any output if it is successful. If you send a signal to a - process that you do not own, you will instead see + any output if it is successful. If a signal is sent to a + process not owned by that user, the message kill: PID: Operation - not permitted. Mistyping the PID will either - send the signal to the wrong process, which could have - negative results, or will send the signal to a PID that is + not permitted will be displayed. Mistyping + the PID will either send the signal to + the wrong process, which could have negative results, or + will send the signal to a PID that is not currently in use, resulting in the error kill: PID: No such process. Why Use <command>/bin/kill</command>? Many shells provide kill as a built in command, meaning that the shell will send the signal directly, rather than running /bin/kill. Be aware that different shells have a different syntax for specifying the name of the signal to send. Rather than try to learn all of them, it can be simpler to use /bin/kill ... directly. When sending other signals, substitute TERM or KILL in the command line as necessary. Killing a random process on the system can be a bad idea. - In particular, &man.init.8;, PID 1, is special. Running - /bin/kill -s KILL 1 is a quick, and - unrecommended, way to shutdown the system. + In particular, &man.init.8;, PID 1, is + special. Running /bin/kill -s KILL 1 is + a quick, and unrecommended, way to shutdown the system. Always double check the arguments to &man.kill.1; before pressing Return. Shells shells command line &os; provides a command line interface called a shell. A shell receives commands from the input channel and executes them. Many shells provide built in functions to help with everyday tasks such as file management, file globbing, command line editing, command macros, and environment variables. &os; - comes with several shells, including sh, the - Bourne Shell, and tcsh, the improved C-shell. - Other shells are available from the &os; Ports Collection, such - as zsh and bash. + comes with several shells, including the Bourne shell + (&man.sh.1;) and the extended C shell (&man.tcsh.1;). Other + shells are available from the &os; Ports Collection, such as + zsh and bash. The shell that is used is really a matter of taste. A C programmer might feel more comfortable with a C-like shell such - as tcsh. A Linux user might prefer + as &man.tcsh.1;. A &linux; user might prefer bash. Each shell has unique properties that may or may not work with a user's preferred working environment, which is why there is a choice of which shell to use. One common shell feature is filename completion. After a user types the first few letters of a command or filename and presses Tab, the shell will automatically complete the rest of the command or filename. Consider two files called foobar and foo.bar. To delete foo.bar, type rm fo[Tab].[Tab]. The shell should print out rm foo[BEEP].bar. The [BEEP] is the console bell, which the shell used to indicate it was unable to complete the filename because there is more than one match. Both foobar and foo.bar start with fo. By typing ., then pressing Tab again, the shell would be able to fill in the rest of the filename. environment variables Another feature of the shell is the use of environment variables. Environment variables are a variable/key pair stored in the shell's environment. This environment can be read by any program invoked by the shell, and thus contains a lot of program configuration. Here is a list of common environment variables and their meanings: Variable Description USER Current logged in user's name. PATH Colon-separated list of directories to search for binaries. DISPLAY - Network name of the Xorg + Network name of the + &xorg; display to connect to, if available. SHELL The current shell. TERM The name of the user's type of terminal. Used to determine the capabilities of the terminal. TERMCAP Database entry of the terminal escape codes to perform various terminal functions. OSTYPE Type of operating system. MACHTYPE The system's CPU architecture. EDITOR The user's preferred text editor. PAGER The user's preferred text pager. MANPATH Colon-separated list of directories to search for manual pages. Bourne shells How to set an environment variable differs between shells. - In tcsh and csh, use + In &man.tcsh.1; and &man.csh.1;, use setenv to set environment variables. In - sh and bash, use + &man.sh.1; and bash, use export to set the current environment variables. This example sets the default EDITOR to /usr/local/bin/emacs for the - tcsh shell: + &man.tcsh.1; shell: &prompt.user; setenv EDITOR /usr/local/bin/emacs The equivalent command for bash would be: &prompt.user; export EDITOR="/usr/local/bin/emacs" To expand an environment variable in order to see its current setting, type a $ character in front of its name on the command line. For example, echo $TERM displays the current $TERM setting. Shells treat special characters, known as meta-characters, as special representations of data. The most common - meta-character is *, which - represents any number of characters in a filename. - Meta-characters can be used to perform filename globbing. For - example, echo * is equivalent to - ls because the shell takes all the files that - match * and echo lists - them on the command line. + meta-character is *, which represents any + number of characters in a filename. Meta-characters can be + used to perform filename globbing. For example, echo + * is equivalent to &man.ls.1; because the shell + takes all the files that match * and + &man.echo.1; lists them on the command line. To prevent the shell from interpreting a special character, escape it from the shell by starting it with a backslash (\). For example, echo $TERM prints the terminal setting whereas echo \$TERM literally prints the string $TERM. Changing Your Shell The easiest way to permanently change the default shell is to use chsh. Running this command will open the editor that is configured in the EDITOR environment variable, which by default - is set to vi. Change - the Shell: line to the full path of the - new shell. + is set to &man.vi.1;. Change the Shell: line + to the full path of the new shell. Alternately, use chsh -s which will set the specified shell without opening an editor. For example, to change the shell to bash: &prompt.user; chsh -s /usr/local/bin/bash The new shell must be present in /etc/shells. If the shell was - installed from the &os; Ports - Collection, it should be automatically added to - this file. If it is missing, add it using this + installed from the &os; Ports Collection as described in + , it should be automatically added + to this file. If it is missing, add it using this command, replacing the path with the path of the shell: &prompt.root; echo /usr/local/bin/bash >> /etc/shells - Then rerun chsh. + Then rerun &man.chsh.1;. Text Editors text editors editors Most &os; configuration is done by editing text files. Because of this, it is a good idea to become familiar with a text editor. &os; comes with a few as part of the base system, and many more are available in the Ports Collection. ee editors - ee + &man.ee.1; - A simple editor to learn is ee, - which stands for easy editor. To start this editor, type - ee filename where + A simple editor to learn is &man.ee.1;, which stands for + easy editor. To start this editor, type ee + filename where filename is the name of the file to be edited. Once inside the editor, all of the commands for manipulating the editor's functions are listed at the top of the display. The caret ^ represents Ctrl, so ^e expands to Ctrle. - To leave ee, press - Esc, then choose the leave - editor option from the main menu. The editor will - prompt you to save any changes if the file has been + To leave &man.ee.1;, press Esc, then choose + the leave editor option from the main menu. + The editor will prompt to save any changes if the file has been modified. - vi + &man.vi.1; editors - vi + &man.vi.1; emacs editors emacs - &os; also comes with more powerful text editors such as - vi as part of the base system. - Other editors, like editors/emacs and + &os; also comes with more powerful text editors, such as + &man.vi.1;, as part of the base system. Other editors, like + editors/emacs and editors/vim, are part of the &os; Ports Collection. These editors offer more functionality at the expense of being a more complicated to learn. Learning a more powerful editor such as vim or Emacs can save more time in the long run. Many applications which modify files or require typed input will automatically open a text editor. To alter the default editor used, set the EDITOR environment - variable as described in the shells section. + variable as described in . Devices and Device Nodes A device is a term used mostly for hardware-related activities in a system, including disks, printers, graphics cards, and keyboards. When &os; boots, the majority of the boot messages refer to devices being detected. A copy of the boot messages are saved to /var/run/dmesg.boot. Each device has a device name and number. For example, acd0 is the first IDE CD-ROM drive, while kbd0 represents the keyboard. Most devices in a &os; must be accessed through special files called device nodes, which are located in /dev. Binary Formats - To understand why &os; uses the &man.elf.5; format,the three - currently dominant executable formats for &unix; + Typically when a command is passed to the shell, the shell + will arrange for an executable file to be loaded into memory and + a new process is created. Executable files can either be a binary + file (usually created by the linker as part of compiling a program) + or a shell script (text file to be interpreted by a binary file, + like &man.sh.1; or &man.perl.1;). The &man.file.1; command can + usually determine what is inside a file. + + Binary files need to have a well defined format for the system + to be able to use them properly. Part of the file will be the + executable machine code (the instructions that tell the CPU what + to do), part of it will be data space with pre-defined values, + part will be data space with no pre-defined values, etc. Through + time, different binary file formats have evolved. + + To understand why &os; uses the &man.elf.5; format, the three + currently dominant, executable formats for &unix; must be described: &man.a.out.5; The oldest and classic &unix; object format. It uses a short and compact header with a &man.magic.5; number at the beginning that is often used to characterize the format. It contains three loaded segments: .text, .data, and .bss, plus a symbol table and a string table. COFF The SVR3 object format. The header comprises a section table which can contain more than just .text, .data, and .bss sections. &man.elf.5; The successor to COFF, featuring multiple sections and 32-bit or 64-bit possible values. One major drawback is that ELF was designed with the assumption that there would be only one ABI per system architecture. That assumption is actually incorrect, and not even in the commercial SYSV world (which has at least three ABIs: SVR4, Solaris, SCO) does it hold true. &os; tries to work around this problem somewhat by providing a utility for branding a known ELF executable with information about its compliant ABI. Refer to &man.brandelf.1; for more information. &os; comes from the classic camp and used the &man.a.out.5; format, a technology tried and proven through many generations of BSD releases, until the beginning of the 3.X branch. Though it was possible to build and run native - ELF binaries and kernels on a &os; - system for some time before that, &os; initially resisted the + ELF binaries and kernels on a &os; system + for some time before that, &os; initially resisted the push to switch to ELF as the default format. Why? When Linux made its painful transition to ELF, it was due to their inflexible jump-table based shared library mechanism, which made the construction of shared libraries difficult for vendors and developers. Since ELF tools offered a solution to the shared library problem and were generally seen as the way forward, the migration cost was accepted as necessary and the transition made. &os;'s shared library mechanism is based more closely on the &sunos; style shared library mechanism and is easy to use. So, why are there so many different formats? Back in the PDP-11 days when simple hardware supported a simple, small system, a.out was adequate for the job of representing binaries. As &unix; was ported, the a.out format was retained because it was sufficient for the early ports of &unix; to architectures like the Motorola 68k or VAXen. Then some hardware engineer decided that if he could force software to do some sleazy tricks, a few gates could be shaved off the design and the CPU core could run faster. a.out was ill-suited for this new kind of hardware, known as RISC. Many formats were developed to get better performance from this hardware than the limited, simple a.out format could offer. COFF, ECOFF, and a few others were invented and their limitations explored before settling on ELF. In addition, program sizes were getting huge while disks and physical memory were still relatively small, so the concept of a shared library was born. The virtual memory system became more sophisticated. While each advancement was done using the a.out format, its usefulness was stretched with each new feature. In addition, people wanted to dynamically load things at run time, or to junk parts of their program after the init code had run to save in core memory and swap space. Languages became more sophisticated and people wanted code called before the main() function automatically. Lots of hacks were done to the a.out format to allow all of these things to happen, and they basically worked for a time. In time, a.out was not up to handling all these problems without an ever increasing overhead in code and complexity. While ELF solved many of these problems, it would be painful to switch from the system that basically worked. So ELF had to wait until it was more painful to remain with a.out than it was to migrate to ELF. As time passed, the build tools that &os; derived their build tools from, especially the assembler and loader, evolved in two parallel trees. The &os; tree added shared libraries and fixed some bugs. The GNU folks that originally wrote these programs rewrote them and added simpler support for building cross compilers and plugging in different formats. Those who wanted to build cross compilers targeting &os; were out of luck - since the older sources that &os; had for - as and ld - were not up to the task. The new GNU tools chain + since the older sources that &os; had for &man.as.1; and + &man.ld.1; were not up to the task. The new GNU tools chain (binutils) supports cross compiling, ELF, shared libraries, and C++ extensions. In addition, many vendors release ELF binaries, and &os; should be able to run them. ELF is more expressive than a.out and allows more extensibility in the base system. The ELF tools are better maintained and offer cross compilation support. ELF may be a little slower than a.out, but trying to measure it can be difficult. There are also numerous details that are different between the two such as how they map pages and handle init code. For More Information Manual Pages manual pages The most comprehensive documentation on &os; is in the form of manual pages. Nearly every program on the system comes with a short reference manual explaining the basic operation and available arguments. These manuals can be viewed using man: &prompt.user; man command where command is the name of - the command you wish to learn about. For example, to learn - more about ls, type: + the command to learn about. For example, to learn more about + &man.ls.1;, type: &prompt.user; man ls The online manual is divided into numbered sections: User commands. System calls and error numbers. Functions in the C libraries. Device drivers. File formats. Games and other diversions. Miscellaneous information. System maintenance and operation commands. Kernel developers. In some cases, the same topic may appear in more than one section of the online manual. For example, there is a - chmod user command and a - chmod() system call. To tell - man which section to display, specify the - section number: + &man.chmod.1; user command and a + chmod() system call. To tell &man.man.1; + which section to display, specify the section number: &prompt.user; man 1 chmod This will display the manual page for the user command - chmod. References to a particular section - of the online manual are traditionally placed in parenthesis - in written documentation, so &man.chmod.1; refers to the - chmod user command and &man.chmod.2; refers - to the system call. + &man.chmod.1;. References to a particular section of the + online manual are traditionally placed in parenthesis in + written documentation, so &man.chmod.1; refers to the user + command and &man.chmod.2; refers to the system call. - If you do not know the command name, use man + If the command name is unknown, use man -k to search for keywords in the command descriptions: &prompt.user; man -k mail This command displays a list of commands that have the keyword mail in their descriptions. This is equivalent to using &man.apropos.1;. - To determine what the commands in - /usr/bin do, + To determine what the commands in /usr/bin do, type: &prompt.user; cd /usr/bin &prompt.user; man -f * or &prompt.user; cd /usr/bin &prompt.user; whatis * GNU Info Files Free Software Foundation &os; includes many applications and utilities produced by the Free Software Foundation (FSF). In addition to manual pages, these programs may include hypertext documents called info files. These can be viewed using - info or, if editors/emacs is installed, the info mode of emacs. To use &man.info.1;, type: &prompt.user; info For a brief introduction, type h. For a quick command reference, type ?. diff --git a/en_US.ISO8859-1/books/handbook/boot/chapter.xml b/en_US.ISO8859-1/books/handbook/boot/chapter.xml index 2f4f619f34..c13bec3bbb 100644 --- a/en_US.ISO8859-1/books/handbook/boot/chapter.xml +++ b/en_US.ISO8859-1/books/handbook/boot/chapter.xml @@ -1,1011 +1,1022 @@ The &os; Booting Process Synopsis booting bootstrap The process of starting a computer and loading the operating system is referred to as the bootstrap process, - or simply booting. &os;'s boot process - provides a great deal of flexibility in customizing what happens - when the system starts, including the ability to select from + or simply booting. &os;'s boot process provides + a great deal of flexibility in customizing what happens when + the system starts, including the ability to select from different operating systems installed on the same computer, different versions of the same operating system, or a different installed kernel. This chapter details the configuration options that can be set. It demonstrates how to customize the &os; boot process, including everything that happens until the &os; kernel has started, probed for devices, and started &man.init.8;. This occurs when the text color of the boot messages changes from bright white to grey. After reading this chapter, you will recognize: The components of the &os; bootstrap system and how they interact. The options that can be passed to the components in the &os; bootstrap in order to control the boot process. The basics of &man.device.hints.5;. This chapter only describes the boot process for &os; running on Intel x86 systems. The Booting Problem Turning on a computer and starting the operating system poses an interesting dilemma. By definition, the computer does not know how to do anything until the operating system is started. This includes running programs from the disk. If the computer can not run a program from the disk without the operating system, and the operating system programs are on the disk, how is the operating system started? This problem parallels one in the book The Adventures of Baron Munchausen. A character had fallen part way down a manhole, and pulled himself out by grabbing his bootstraps, and lifting. In the early days of computing the term bootstrap was applied to the mechanism used to load the operating system, which has become shortened to booting. - BIOS + BIOS Basic Input/Output System - BIOS + BIOS - On x86 hardware the Basic Input/Output System (BIOS) is - responsible for loading the operating system. To do this, the - BIOS looks on the hard disk for the Master Boot Record (MBR), - which must be located on a specific place on the disk. The BIOS - has enough knowledge to load and run the MBR, and assumes that - the MBR can then carry out the rest of the tasks involved in - loading the operating system, possibly with the help of the - BIOS. + On x86 hardware the Basic Input/Output System + (BIOS) is responsible for loading the + operating system. To do this, the BIOS + looks on the hard disk for the Master Boot Record + (MBR), which must be located in a specific + place on the disk. The BIOS has enough + knowledge to load and run the MBR, and + assumes that the MBR can then carry out the + rest of the tasks involved in loading the operating system, + possibly with the help of the BIOS. - Master Boot Record (MBR) + Master Boot Record + MBR) Boot Manager Boot Loader - The code within the MBR is usually referred to as a - boot manager, especially when it interacts - with the user. In this case the boot manager usually has more - code in the first track of the disk or - within some OS's file system. (A boot manager is sometimes also - called a boot loader, but &os; uses that - term for a later stage of booting.) Popular boot managers - include boot0 (aka + The code within the MBR is usually + referred to as a boot manager, especially + when it interacts with the user. In this case, the boot + manager usually has more code in the first + track of the disk or within the file + system of some operating systems. A boot manager is sometimes + also called a boot loader, but &os; uses + that term for a later stage of booting. Popular boot managers + include boot0, also called Boot Easy, the standard &os; boot - manager), Grub, + manager, Grub, GAG, and - LILO. (Only - boot0 fits within the MBR.) + LILO. Only + boot0 fits within the + MBR. - If only one operating system is installed, a standard PC MBR - will suffice. This MBR searches for the first bootable (active) + If only one operating system is installed, a standard PC + MBR will suffice. This + MBR searches for the first bootable (active) slice on the disk, and then runs the code on that slice to load - the remainder of the operating system. By default, the MBR - installed by &man.fdisk.8; is such an MBR and is based on + the remainder of the operating system. By default, the + MBR installed by &man.fdisk.8; is such an + MBR and is based on /boot/mbr. If multiple operating systems are present, a different boot manager can be installed which displays the list of operating systems so that the user can choose which one to boot from. Two boot managers are discussed in the next subsection. The remainder of the &os; bootstrap system is divided - into three stages. The first stage is run by the MBR, which - knows just enough to get the computer into a specific state and - run the second stage. The second stage can do a little bit - more, before running the third stage. The third stage finishes - the task of loading the operating system. The work is split - into three stages because PC standards put limits on the size of - the programs that can be run at stages one and two. Chaining - the tasks together allows &os; to provide a more flexible - loader. + into three stages. The first stage is run by the + MBR, which knows just enough to get the + computer into a specific state and run the second stage. The + second stage can do a little bit more, before running the + third stage. The third stage finishes the task of loading the + operating system. The work is split into three stages because + PC standards put limits on the size of the programs that can + be run at stages one and two. Chaining the tasks together + allows &os; to provide a more flexible loader. kernel - init + &man.init.8; The kernel is then started and it begins to probe for devices and initialize them for use. Once the kernel boot process is finished, the kernel passes control to the user process &man.init.8;, which then makes sure the disks are in a usable state. &man.init.8; then starts the user-level resource configuration which mounts file systems, sets up network cards to communicate on the network, and starts the processes which have been configured to run on a &os; system at startup. The Boot Manager and Boot Stages Boot Manager The Boot Manager Master Boot Record - (MBR) + (MBR) - The code in the MBR or boot manager is sometimes referred - to as stage zero of the boot process. - This section discusses two boot managers: + The code in the MBR or boot manager is + sometimes referred to as stage zero of + the boot process. This section discusses two boot managers: boot0 and LILO. The <application>boot0</application> Boot Manager: - The MBR installed by &os;'s installer or - &man.boot0cfg.8; is based on + The MBR installed by &os;'s installer + or &man.boot0cfg.8; is based on /boot/boot0. The size and capability of boot0 is restricted to 446 bytes due to the slice table and 0x55AA - identifier at the end of the MBR. If + identifier at the end of the MBR. If boot0 and multiple operating systems are installed, a message similar to this example will be displayed at boot time: <filename>boot0</filename> Screenshot F1 Win F2 FreeBSD Default: F2 Other operating systems, in particular &windows;, will - overwrite an existing MBR if they are installed after &os;. - If this happens, or you want to replace the existing MBR - with the &os; MBR, use the following command: + overwrite an existing MBR if they are + installed after &os;. If this happens, or to replace the + existing MBR with the &os; + MBR, use the following command: &prompt.root; fdisk -B -b /boot/boot0 device where device is the boot disk, - such as ad0 for the first IDE disk, - ad2 for the first IDE disk on a - second IDE controller, or da0 - for the first SCSI disk. To create a custom configuration of - the MBR, refer to &man.boot0cfg.8;. + such as ad0 for the first + IDE disk, ad2 + for the first IDE disk on a second + IDE controller, or + da0 + for the first SCSI disk. To create a + custom configuration of the MBR, refer to + &man.boot0cfg.8;. The LILO Boot Manager: To install this boot manager so it will also boot &os;, boot into Linux and add the following to the existing /etc/lilo.conf configuration: other=/dev/hdXY table=/dev/hdX loader=/boot/chain.b label=FreeBSD Specify &os;'s primary partition and drive using Linux specifiers, replacing X with the Linux drive letter and Y with the Linux primary partition number. For a SCSI drive, change /dev/hd to /dev/sd. The line can be omitted if both operating systems are installed on the same drive. Next, run /sbin/lilo -v to commit the new changes. Verify these are correct by checking the screen messages. Stage One, <filename>/boot/boot1</filename>, and Stage Two, <filename>/boot/boot2</filename> Conceptually, the first and second stages are part of the same program, on the same area of the disk. Because of space constraints, they have been split into two, but are always installed together. They are copied from the combined /boot/boot by the installer or - bsdlabel. + &man.bsdlabel.8;. They are located outside file systems, in the first track of the boot slice, starting with the first sector. This is - where boot0, or any other + where boot0 (), or any other boot manager, expects to find a program to run which will continue the boot process. The number of sectors used is easily determined from the size of /boot/boot. boot1 is very simple, since it can only be 512 bytes in size, and knows just enough about the &os; bsdlabel, which stores information about the slice, to find and execute boot2. boot2 is slightly more sophisticated, and understands the &os; file system enough to find files, and can provide a simple interface to choose the kernel or loader to run. - loader is much more - sophisticated and provides a boot configuration which is run - by boot2. + However, &man.loader.8; is much more sophisticated and + provides a boot configuration which is run by + boot2. <filename>boot2</filename> Screenshot >> FreeBSD/i386 BOOT Default: 0:ad(0,a)/boot/loader boot: &man.bsdlabel.8; can be used to replace the installed boot1 and boot2: &prompt.root; bsdlabel -B diskslice where diskslice is the disk and slice to boot from, such as ad0s1 - for the first slice on the first IDE disk. + for the first slice on the first IDE + disk. Dangerously Dedicated Mode If just the disk name is used, such as ad0, &man.bsdlabel.8; will create a dangerously dedicated disk, without slices. This is probably not the desired action, so double check the diskslice passed to &man.bsdlabel.8; before pressing Return. Stage Three, <filename>/boot/loader</filename> boot-loader The loader is the final stage of the three-stage bootstrap, and is located on the file system, usually as /boot/loader. The loader is intended as an interactive method for configuration, using a built-in command set, backed up by a more powerful interpreter which has a more complex command set. Loader Program Flow During initialization, the loader will probe for a console and for disks, and figure out which disk it is booting from. It will set variables accordingly, and an interpreter is started where user commands can be passed from a script or interactively. loader loader configuration The loader will then read /boot/loader.rc, which by default reads in /boot/defaults/loader.conf which sets reasonable defaults for variables and reads /boot/loader.conf for local changes to those variables. loader.rc then acts on these variables, loading whichever modules and kernel are selected. Finally, by default, the loader issues a 10 second wait for key presses, and boots the kernel if it is not interrupted. If interrupted, the user is presented with a prompt which understands the command set, where the user may adjust variables, unload all modules, load modules, and then finally boot or reboot. Loader Built-In Commands These are the most commonly used loader commands. For a complete discussion of all available commands, refer to &man.loader.8;. autoboot seconds Proceeds to boot the kernel if not interrupted within the time span given, in seconds. It displays a countdown, and the default time span is 10 seconds. boot -options kernelname Immediately proceeds to boot the kernel, with any specified options or kernel name. Providing a kernel name on the command-line is only applicable after an unload command has been issued; otherwise the previously-loaded kernel will be used. boot-conf Goes through the same automatic configuration of modules based on specified variables, most commonly kernel. This only makes sense if unload is used first, before changing some variables. help topic Shows help messages read from /boot/loader.help. If the topic given is index, the list of available topics is displayed. include filename … Processes the file with the given filename. The file is read in and interpreted line by line. An error immediately stops the include command. load type filename Loads the kernel, kernel module, or file of the type given, with the specified filename. Any arguments after filename are passed to the file. ls path Displays a listing of files in the given path, or the root directory, if the path is not specified. If is specified, file sizes will also be shown. lsdev Lists all of the devices from which it may be possible to load modules. If is specified, more details are printed. lsmod Displays loaded modules. If is specified, more details are shown. more filename Displays the files specified, with a pause at each LINES displayed. reboot Immediately reboots the system. set variable set variable=value Sets the loader's environment variables. unload Removes all loaded modules. Loader Examples Here are some practical examples of loader usage: single-user mode To boot the usual kernel in single-user mode: boot -s To unload the usual kernel and modules, and then load the previous or another kernel: kernel.old unload load kernel.old Use kernel.GENERIC to refer to the default kernel that comes with an installation, or kernel.old to refer to the previously installed kernel before a system upgrade or before configuring a custom kernel. Use the following to load the usual modules with another kernel: unload set kernel="kernel.old" boot-conf To load an automated kernel configuration script: load -t userconfig_script /boot/kernel.conf Joseph J. Barbish Contributed by Boot Time Splash Screens The splash screen creates an alternate boot screen. The splash screen hides all the boot probe messages and service startup messages before displaying either a command line or graphical login prompt. There are two basic environments available in &os;. The first is the default legacy virtual console command line environment. After the system finishes booting, a console login prompt is presented. The second environment is the - graphical environment provided by - Xorg. Refer to that chapter for - more information on how to install and configure a graphical - display manager and a graphical login manager. + graphical environment as described in . + Refer to that chapter for more information on how to install + and configure a graphical display manager and a graphical + login manager. Splash Screen Function The splash screen function supports 256-colors in the bitmap (.bmp), ZSoft PCX (.pcx), or TheDraw (.bin) formats. The splash image files must have a resolution of 320 by 200 pixels or less in order to work on standard VGA adapters. To use larger images, up to the maximum resolution of 1024 by 768 pixels, load the VESA - module during system boot. For a custom kernel, include the + module during system boot. For a custom kernel, as + described in , include the VESA kernel configuration option. Loading VESA support provides the ability to display a splash screen image that fills the whole display screen. While the splash screen is being displayed during the booting process, it can be turned off any time by hitting any key on the keyboard. The splash screen also defaults to being a screen saver outside. After a time period of non-use, the splash screen will be displayed and will cycle through steps of changing intensity of the image, from bright to very dark and over again. The configuration of the splash screen saver can be overridden by adding a saver= line to /etc/rc.conf. Several built-in screen savers are available and described in &man.splash.4;. The saver= option only applies to virtual consoles and has no effect on graphical display managers. A few boot loader messages, including the boot options menu and a timed wait count down prompt, are displayed at boot time, even when the splash screen is enabled. Sample splash screen files can be downloaded from the gallery at http://artwork.freebsdgr.org. By installing the sysutils/bsd-splash-changer port, splash images can be chosen from a collection randomly at each boot. Enabling the Splash Screen Function The splash screen .bmp, .pcx, or .bin image has to be placed on the root partition, for example in /boot. For the default boot display resolution of 256-colors and 320 by 200 pixels or less, edit /boot/loader.conf so it contains the following: splash_bmp_load="YES" bitmap_load="YES" bitmap_name="/boot/splash.bmp" For larger video resolutions up to the maximum of 1024 by 768 pixels, edit /boot/loader.conf, so it contains the following: vesa_load="YES" splash_bmp_load="YES" bitmap_load="YES" bitmap_name="/boot/splash.bmp" This example assumes that /boot/splash.bmp is used for the splash screen. To use a PCX file, use the following statements, plus the vesa_load="YES" line, depending on the resolution: splash_pcx_load="YES" bitmap_load="YES" bitmap_name="/boot/splash.pcx" Beginning with &os; 8.3, another option is to use ASCII art in TheDraw format. splash_txt="YES" bitmap_load="YES" bitmap_name="/boot/splash.bin" The file name is not restricted to splash as shown in the above example. It can be anything as long as it is one of the supported types such as, splash_640x400.bmp or bluewave.pcx. - Other interesting - loader.conf options include: + Other interesting loader.conf + options include: beastie_disable="YES" This will stop the boot options menu from being displayed, but the timed wait count down prompt will still be present. Even with the display of the boot options menu disabled, entering an option selection at the timed wait count down prompt will enact the corresponding boot option. loader_logo="beastie" This will replace the default words &os;, which are displayed to the right of the boot options menu with the colored beastie logo. For more information, refer to &man.splash.4;, &man.loader.conf.5;, and &man.vga.4;. Kernel Interaction During Boot kernel boot interaction - Once the kernel is loaded by either the default loader or by boot2 which bypasses the loader, - it examines its boot flags, if any, and adjusts its behavior as + Once the kernel is loaded by either the default loader + () or by boot2 (), which bypasses the loader, it + examines any boot flags and adjusts its behavior as necessary. Kernel Boot Flags kernel bootflags Here are the more common boot flags: During kernel initialization, ask for the device to mount as the root file system. Boot from CDROM. Run UserConfig, the boot-time kernel configurator. Boot into single-user mode. Be more verbose during kernel startup. Refer to &man.boot.8; for more information on the other boot flags. Tom Rhodes Contributed by Device Hints device.hints During initial system startup, the boot &man.loader.8; reads &man.device.hints.5;. This file stores kernel boot information known as variables, sometimes referred to as device hints. These device hints are used by device drivers for device configuration. - Device hints may also be specified at the Stage 3 boot loader prompt. + Device hints may also be specified at the Stage 3 boot + loader prompt, as demonstrated in . Variables can be added using set, removed with unset, and viewed show. Variables set in /boot/device.hints can also be overridden. Device hints entered at the boot loader are not permanent and will not be applied on the next reboot. Once the system is booted, &man.kenv.1; can be used to dump all of the variables. The syntax for /boot/device.hints is one variable per line, using the hash # as comment markers. Lines are constructed as follows: hint.driver.unit.keyword="value" The syntax for the Stage 3 boot loader is: set hint.driver.unit.keyword=value where driver is the device driver name, unit is the device driver unit number, and keyword is the hint keyword. The keyword may consist of the following options: at: specifies the bus which the device is attached to. port: specifies the start address of the I/O to be used. irq: specifies the interrupt request number to be used. drq: specifies the DMA channel number. maddr: specifies the physical memory address occupied by the device. flags: sets various flag bits for the device. disabled: if set to 1 the device is disabled. Since device drivers may accept or require more hints not listed here, viewing a driver's manual page is recommended. For more information, refer to &man.device.hints.5;, &man.kenv.1;, &man.loader.conf.5;, and &man.loader.8;. Init: Process Control Initialization - init + &man.init.8; Once the kernel has finished booting, it passes control to the user process &man.init.8;, which is located at /sbin/init, or the program path specified in the init_path variable in loader. Automatic Reboot Sequence The automatic reboot sequence makes sure that the file systems available on the system are consistent. If they are not, and &man.fsck.8; cannot fix the inconsistencies of a UFS - file system, &man.init.8; drops the system into - single-user mode so - that the system administrator can resolve the problem - directly. + file system, &man.init.8; drops the system into single-user + mode () so that the system + administrator can resolve the problem directly. Single-User Mode single-user mode console - This mode can be reached through the automatic reboot sequence, - the user booting with , or by setting - the boot_single variable in - loader. + This mode can be reached through the automatic reboot + sequence (), the user booting + with , or by setting the boot_ + single variable in &man.loader.8;. It can also be reached by calling &man.shutdown.8; from - multi-user mode without + multi-user mode () without including or . If the system console is set to insecure in /etc/ttys, the system will prompt for the root password before initiating single-user mode. An Insecure Console in <filename>/etc/ttys</filename> # name getty type status comments # # If console is marked "insecure", then init will ask for the root password # when going to single-user mode. console none unknown off insecure An insecure console means that physical security to the console is considered to be insecure, so only someone who knows the root password may use single-user mode. Thus, to add this measure of security, choose insecure, instead of the default of secure. Multi-User Mode multi-user mode If &man.init.8; finds the file systems to be in order, or - once the user has finished their commands in single-user mode, the - system enters multi-user mode, in which it starts the - resource configuration of the system. + once the user has finished their commands in single-user + mode (), the system enters + multi-user mode, in which it starts the resource configuration + of the system. - Resource Configuration (rc) + Resource Configuration rc files The resource configuration system reads in configuration defaults from /etc/defaults/rc.conf, and system-specific details from /etc/rc.conf, and then proceeds to mount the system file systems listed in /etc/fstab. It starts up networking services, miscellaneous system daemons, then the startup scripts of locally installed packages. To learn more about the resource configuration system, refer to &man.rc.8; and examine the scripts themselves. Shutdown Sequence - shutdown + &man.shutdown.8; Upon controlled shutdown using &man.shutdown.8;, &man.init.8; will attempt to run the script /etc/rc.shutdown, and then proceed to send all processes the TERM signal, and subsequently the KILL signal to any that do not terminate in a timely manner. To power down a &os; machine on architectures and systems that support power management, use shutdown -p now to turn the power off immediately. To reboot a &os; system, use shutdown -r now. One must - be root or a member of the - operator group in order to run + be root or a member of + operator in order to run &man.shutdown.8;. One can also use &man.halt.8; and &man.reboot.8;. Refer to their manual pages and to &man.shutdown.8; for more information. Power management requires &man.acpi.4; to be loaded as a module or staticly compiled into a custom kernel. diff --git a/en_US.ISO8859-1/books/handbook/config/chapter.xml b/en_US.ISO8859-1/books/handbook/config/chapter.xml index fba2a7c58b..1653f20602 100644 --- a/en_US.ISO8859-1/books/handbook/config/chapter.xml +++ b/en_US.ISO8859-1/books/handbook/config/chapter.xml @@ -1,3492 +1,3486 @@ Chern Lee Written by Mike Smith Based on a tutorial written by Matt Dillon Also based on tuning(7) written by Configuration and Tuning Synopsis system configuration system optimization One of the important aspects of &os; is proper system configuration. This chapter explains much of the &os; configuration process, including some of the parameters which can be set to tune a &os; system. After reading this chapter, you will know: How to efficiently work with file systems and swap partitions. The basics of rc.conf configuration and /usr/local/etc/rc.d startup scripts. How to configure and test a network card. How to configure virtual hosts on network devices. - How to use the various configuration files in - /etc. + How to use the various configuration files in /etc. - How to tune &os; using sysctl - variables. + How to tune &os; using &man.sysctl.8; variables. How to tune disk performance and modify kernel limitations. Before reading this chapter, you should: Understand &unix; and &os; basics (). Be familiar with the basics of kernel configuration and compilation (). Initial Configuration Partition Layout partition layout /etc /var /usr Base Partitions When laying out file systems with &man.bsdlabel.8; or &man.sysinstall.8;, remember that hard drives transfer data - faster from the outer tracks to the inner. Thus smaller and - heavier-accessed file systems should be closer to the + faster from the outer tracks to the inner. Thus, smaller + and heavier-accessed file systems should be closer to the outside of the drive, while larger partitions like /usr should be placed toward the inner parts of the disk. It is a good idea to - create partitions in an order similar to: root, swap, - /var, + create partitions in an order similar to: /, swap, + /var, and /usr. The size of the /var partition reflects the intended machine's usage. This partition - /var is used to hold - mailboxes, log files, and printer spools. Mailboxes and log - files can grow to unexpected sizes depending on how many - users exist and how long log files are kept. Most users - rarely need more than about a gigabyte of free disk space in - /var. + is used to hold mailboxes, log files, and printer spools. + Mailboxes and log files can grow to unexpected sizes + depending on the number of users and how long log files + are kept. On average, most users rarely need more than + about a gigabyte of free disk space in /var. - There are a few times that a lot of disk space is - required in - /var/tmp. When new - software is installed with &man.pkg.add.1; the packaging - tools extract a temporary copy of the packages under - /var/tmp. Large - software packages, like + Sometimes, a lot of disk space is required in + /var/tmp. When + new software is installed with &man.pkg.add.1;, the + packaging tools extract a temporary copy of the packages + under /var/tmp. + Large software packages, like Firefox, OpenOffice or LibreOffice may be tricky to - install if there is not enough disk space under - /var/tmp. + install if there is not enough disk space under /var/tmp. The /usr partition holds many of the files which support the system, including the &os; Ports Collection and system source code. At least 2 gigabytes is recommended for this partition. When selecting partition sizes, keep the space - requirements in mind. Running out of space in - one partition while barely using another can be a - hassle. + requirements in mind. Running out of space in one partition + while barely using another can be a hassle. - Some users have found that &man.sysinstall.8;'s - Auto-defaults partition sizer will - sometimes select smaller than adequate - /var and - / partitions. + The Auto-defaults partition sizer + used by &man.sysinstall.8; will sometimes select smaller + than adequate /var + and / partitions. Partition wisely and generously. Swap Partition swap sizing swap partition As a rule of thumb, the swap partition should be about - double the size of physical memory (RAM) as the kernel's - virtual memory (VM) paging algorithms are tuned to perform - best when the swap partition is at least two times - the size of main memory. Systems with minimal RAM may - perform better with more swap. Configuring too little swap - can lead to inefficiencies in the VM page scanning code and - might create issues later if more memory is added. - - On larger systems with multiple SCSI disks or multiple - IDE disks operating on different controllers, it is - recommended that swap be configured on each drive (up to - four drives). The swap partitions should be approximately - the same size. The kernel can handle arbitrary sizes but - internal data structures scale to 4 times the largest swap - partition. Keeping the swap partitions near the same size - will allow the kernel to optimally stripe swap space across - disks. Large swap sizes are fine, even if swap is not used - much. It might be easier to recover from a runaway program - before being forced to reboot. + double the size of physical memory (RAM) + as the kernel's virtual memory (VM) + paging algorithms are tuned to perform best when the swap + partition is at least two times the size of main memory. + Systems with minimal RAM may perform + better with more swap. Configuring too little swap can + lead to inefficiencies in the VM page + scanning code and might create issues later if more memory + is added. + + On larger systems with multiple SCSI + disks or multiple IDE disks operating + on different controllers, it is recommended that swap be + configured on each drive, up to four drives. The swap + partitions should be approximately the same size. The + kernel can handle arbitrary sizes but internal data + structures scale to 4 times the largest swap partition. + Keeping the swap partitions near the same size will allow + the kernel to optimally stripe swap space across disks. + Large swap sizes are fine, even if swap is not used much. + It might be easier to recover from a runaway program before + being forced to reboot. Why Partition? Several users think a single large partition will be fine, but there are several reasons why this is a bad idea. First, each partition has different operational characteristics and separating them allows the file system - to tune accordingly. For example, the root and - /usr partitions are + to tune accordingly. For example, the root and /usr partitions are read-mostly, with few writes, while a lot of reads and - writes could occur in - /var and - /var/tmp. + writes could occur in /var and /var/tmp. By properly partitioning a system, fragmentation introduced in the smaller write heavy partitions will not - bleed over into the mostly-read partitions. Keeping the - write-loaded partitions closer to the disk's edge, will + bleed over into the mostly read partitions. Keeping the + write loaded partitions closer to the disk's edge will increase I/O performance in the partitions where it occurs - the most. Now while I/O performance in the larger - partitions may be needed, shifting them more toward the edge - of the disk will not lead to a significant performance - improvement over moving - /var to the edge. - Finally, there are safety concerns. A smaller, neater root + the most. While I/O performance in the larger partitions + may be needed, shifting them more toward the edge of the + disk will not lead to a significant performance + improvement over moving /var to the edge. Finally, + there are safety concerns. A smaller, neater root partition which is mostly read-only has a greater chance of surviving a bad crash. Core Configuration rc files rc.conf The principal location for system configuration information - is /etc/rc.conf. This file contains - a wide range of configuration information and it is read at + is /etc/rc.conf. This file contains a + wide range of configuration information and it is read at system startup to configure the system. It provides the configuration information for the rc* files. The entries in /etc/rc.conf override the default settings in /etc/defaults/rc.conf. The file containing the default settings should not be edited. Instead, all system-specific changes should be made to /etc/rc.conf. A number of strategies may be applied in clustered applications to separate site-wide configuration from system-specific configuration in order to keep administration overhead down. The recommended approach is to place system-specific configuration into - /etc/rc.conf.local. For - example: + /etc/rc.conf.local. For example: /etc/rc.conf: sshd_enable="YES" keyrate="fast" defaultrouter="10.1.1.254" /etc/rc.conf.local: hostname="node1.example.org" ifconfig_fxp0="inet 10.1.1.1/8" - rc.conf can then be - distributed to every system using rsync or a - similar program, while rc.conf.local - remains unique. + Distribute /etc/rc.conf to every + system using rsync or a similar program, + while /etc/rc.conf.local remains + unique. Upgrading the system using &man.sysinstall.8; or make world will not overwrite - rc.conf, so system configuration + /etc/rc.conf, so system configuration information will not be lost. - The /etc/rc.conf configuration file + The configuration in /etc/rc.conf is parsed by &man.sh.1;. This allows system operators to - add a certain amount of logic to this file, which may help to - create very complex configuration scenarios. Refer to + create complex configuration scenarios. Refer to &man.rc.conf.5; for further information on this topic. Application Configuration Typically, installed applications have their own configuration files and syntax. It is important that these files be kept separate from the base system, so that they may be easily located and managed by the package management tools. /usr/local/etc - Typically, these files are installed in - /usr/local/etc. In the - case where an application has a large number of configuration + Typically, these files are installed in /usr/local/etc. In the case + where an application has a large number of configuration files, a subdirectory will be created to hold them. Normally, when a port or package is installed, sample configuration files are also installed. These are usually - identified with a .default suffix. If - there are no existing configuration files for the application, - they will be created by copying the - .default files. + identified with a suffix such as .sample. + If there are no existing configuration files for the + application, they can be created by copying the sample + files. For example, consider the contents of the directory /usr/local/etc/apache: -rw-r--r-- 1 root wheel 2184 May 20 1998 access.conf -rw-r--r-- 1 root wheel 2184 May 20 1998 access.conf.default -rw-r--r-- 1 root wheel 9555 May 20 1998 httpd.conf -rw-r--r-- 1 root wheel 9555 May 20 1998 httpd.conf.default -rw-r--r-- 1 root wheel 12205 May 20 1998 magic -rw-r--r-- 1 root wheel 12205 May 20 1998 magic.default -rw-r--r-- 1 root wheel 2700 May 20 1998 mime.types -rw-r--r-- 1 root wheel 2700 May 20 1998 mime.types.default -rw-r--r-- 1 root wheel 7980 May 20 1998 srm.conf -rw-r--r-- 1 root wheel 7933 May 20 1998 srm.conf.default - The file sizes show that only - srm.conf has been changed. A later - update of the Apache port would not - overwrite this changed file. + The file sizes show that only srm.conf + has been changed. A later update of the + Apache port would not overwrite + this changed file. Tom Rhodes Contributed by Starting Services services Many users install third party software on &os; from the Ports Collection and require the installed services to be - started upon system initialization. Services, - such as mail/postfix or - www/apache22 are just two of - the many software packages which may be started during system + started upon system initialization. Services, such as + mail/postfix or + www/apache22 are just two + of the many software packages which may be started during system initialization. This section explains the procedures available for starting third party software. In &os;, most included services, such as &man.cron.8;, are started through the system start up scripts. Extended Application Configuration Now that &os; includes rc.d, configuration of application startup is easier and provides - more features. Using the key words discussed in the - rc.d section, - applications can be set to start after certain other services - and extra flags can be passed through - /etc/rc.conf in place of hard coded flags - in the start up script. A basic script may look similar to - the following: + more features. Using the key words discussed in , applications can be set to + start after certain other services and extra flags can be + passed through /etc/rc.conf in place of + hard coded flags in the start up script. A basic script may + look similar to the following: #!/bin/sh # # PROVIDE: utility # REQUIRE: DAEMON # KEYWORD: shutdown . /etc/rc.subr name=utility rcvar=utility_enable command="/usr/local/sbin/utility" load_rc_config $name # # DO NOT CHANGE THESE DEFAULT VALUES HERE # SET THEM IN THE /etc/rc.conf FILE # utility_enable=${utility_enable-"NO"} pidfile=${utility_pidfile-"/var/run/utility.pid"} run_rc_command "$1" This script will ensure that the provided - utility will be started after the + utility will be started after the DAEMON pseudo-service. It also provides a - method for setting and tracking the PID, or - process ID file. + method for setting and tracking the process ID + (PID). This application could then have the following line placed in /etc/rc.conf: utility_enable="YES" - This method also allows for easier manipulation of the - command line arguments, inclusion of the default functions - provided in /etc/rc.subr, compatibility - with the &man.rcorder.8; utility and provides for easier - configuration via rc.conf. + This method allows for easier manipulation of command + line arguments, inclusion of the default functions provided + in /etc/rc.subr, compatibility with + &man.rcorder.8;, and provides for easier configuration via + rc.conf. Using Services to Start Services - Other services, such as the POP3 server - daemons or IMAP, could be started using - &man.inetd.8;. This involves installing the service utility - from the Ports Collection with a configuration line added to - /etc/inetd.conf, or by - uncommenting one of the current configuration lines. Working - with inetd and its configuration is - described in depth in the - inetd section. - - In some cases it may make more sense to use the - &man.cron.8; daemon to start system services. This approach - has a number of advantages because cron - runs these processes as the crontab's - file owner. This allows regular users to start and maintain - some applications. - - The cron utility provides a unique - feature, @reboot, which may be used in - place of the time specification. This will cause the job to - be run when &man.cron.8; is started, normally during system - initialization. + Other services can be started using &man.inetd.8;. + Working with &man.inetd.8; and its configuration is + described in depth in + . + + In some cases, it may make more sense to use + &man.cron.8; to start system services. This approach + has a number of advantages as &man.cron.8; runs these + processes as the owner of the &man.crontab.5;. This allows + regular users to start and maintain their own + applications. + + The @reboot feature of &man.cron.8;, + may be used in place of the time specification. This causes + the job to run when &man.cron.8; is started, normally during + system initialization. Tom Rhodes Contributed by - Configuring the <command>cron</command> Utility + Configuring &man.cron.8; cron configuration One of the most useful utilities in &os; is &man.cron.8;. This utility runs in the background and regularly checks /etc/crontab for tasks to execute and - searches - /var/cron/tabs for custom - crontab files. These files store - information about specific functions which - cron is supposed to perform at certain - times. - - The cron utility uses two different types - of configuration files, the system crontab and user crontabs. - These formats only differ in the sixth field and later. In the - system crontab, cron will run the command as - the user specified in the sixth field. In a user crontab, all - commands run as the user who created the crontab, so the sixth - field is the last field; this is an important security feature. + searches /var/cron/tabs + for custom &man.crontab.5; files. These files store + information about specific functions which &man.cron.8; is + supposed to perform at certain times. + + Two different types of configuration files are used by + &man.cron.8;: the system crontab and user + crontabs. These formats only differ in + the sixth field and later. In the system + crontab, &man.cron.8; runs the command as + the user specified in the sixth field. In a user + crontab, all commands run as the user who + created the crontab, so the sixth field + is the last field; this is an important security feature. The final field is always the command to run. User crontabs allow individual users to schedule tasks without the need for root privileges. Commands in a user's crontab run with the permissions of the user who owns the crontab. - The root user can have a user crontab - just like any other user. The root user - crontab is separate from /etc/crontab - (the system crontab). Because the system crontab effectively - invokes the specified commands as root there is usually no - need to create a user crontab for + The root user can have a user + crontab just like any other user. The + root user crontab + is separate from the system crontab, + /etc/crontab. Because the system + crontab invokes the specified commands as + root, there is usually no need to create + a user crontab for root. - Let us take a look at /etc/crontab, - the system crontab: + Here is a sample entry from + /etc/crontab: - # /etc/crontab - root's crontab for &os; + # /etc/crontab - root's crontab for FreeBSD # -# $&os;: src/etc/crontab,v 1.32 2002/11/22 16:13:39 tom Exp $ +# $FreeBSD$ # # SHELL=/bin/sh PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin -HOME=/var/log -# # #minute hour mday month wday who command # -# */5 * * * * root /usr/libexec/atrun Like most &os; configuration files, lines that begin with the # character are comments. A comment can be placed in the file as a reminder of what and why a desired action is performed. Comments cannot be on the same line as a command or else they will be interpreted as part of the command; they must be on a new line. Blank lines are ignored. - First, the environment must be defined. The equals - (=) character is used to define any - environment settings, as with this example where it is used - for the SHELL, PATH, and - HOME options. If the shell line is omitted, - cron will use the default, which is - sh. If the PATH variable - is omitted, no default will be used and file locations will - need to be absolute. If HOME is omitted, - cron will use the invoking users home - directory. + The equals (=) character is used to + define any environment settings. In this example, it is + used to define the SHELL and + PATH. If the SHELL is + omitted, &man.cron.8; will use the default of &man.sh.1;. + If the PATH is omitted, no default will be + used and file locations will need to be absolute. - This line defines a total of seven fields. Listed here - are the values minute, + This line defines a total of seven fields: + minute, hour, mday, month, wday, who, and command. These are almost all self explanatory. - minute is the time in minutes the command - will be run. hour is similar to the - minute option, just in hours. - mday stands for day of the month. - month is similar to - hour and minute, as it - designates the month. The wday option - stands for day of the week. All these fields must be - numeric values, and follow the twenty-four hour clock. The - who field is special, and only exists in - /etc/crontab. This field specifies - which user the command should be run as. The last field is - the command to be executed. + minute is the time in minutes when the + specified command will be run. hour is + the hour when the specified command will be run. + mday stands for day of the month and + month designates the month. The + wday option stands for day of the week. + These fields must be numeric values, representing the + twenty-four hour clock, or a *, + representing all values for that field. The + who field only exists in the system + crontab. This field specifies which user the command + should be run as. The last field is the command to be + executed. - This last line will define the values discussed above. + This last line defines the values discussed above. This example has a */5 listing,followed by several more * characters. These * characters mean first-last, and can be interpreted as every time. In this example, - atrun is invoked by - root every five minutes regardless of - the day or month. For more information on - atrun, refer to &man.atrun.8;. + &man.atrun.8; is invoked by root + every five minutes, regardless of the day or month. Commands can have any number of flags passed to them; however, commands which extend to multiple lines need to be broken with the backslash \ continuation character. - This is the basic setup for every - crontab, although there is one thing - different about this one. Field number six, which specifies - the username, only exists in the system - crontab. This field should be omitted for - individual user crontab files. + This is the basic setup for every &man.crontab.5;. + However, field number six, which specifies the username, only + exists in the system &man.crontab.5;. This field should be + omitted for individual user &man.crontab.5; files. Installing a Crontab Do not use the procedure described here to edit and - install the system crontab, + install the system crontab, /etc/crontab. Instead, use an - editor: cron will notice that the file - has changed and immediately begin using the updated version. + editor and &man.cron.8; will notice that the file has + changed and immediately begin using the updated version. See this FAQ entry for more information. - To install a freshly written user - crontab, first use an editor to create - and save a file in the proper format. Then, specify the file - name with crontab: + To install a freshly written user &man.crontab.5;, use + an editor to create and save a file in the proper format. + Then, specify the file name with &man.crontab.1;: &prompt.user; crontab crontab-file In this example, crontab-file is the - filename of a crontab that was previously + filename of a &man.crontab.5; that was previously created. - To list installed crontab files, pass - to crontab. + To list installed &man.crontab.5; files, pass + to &man.crontab.1;. - For users who wish to begin their own crontab file from - scratch, without the use of a template, the - crontab -e option is available. This will - invoke the selected editor with an empty file. When the file - is saved, it will be automatically installed by - crontab. + Users who wish to begin their own + crontab file from scratch, without the + use of a template, can use crontab -e. This + will invoke the default editor with an empty file. When this + file is saved, it will be automatically installed by + &man.crontab.1;. - In order to remove a user crontab - completely, use crontab -r. + In order to remove a user &man.crontab.5; completely, + use crontab -r. Tom Rhodes Contributed by Using &man.rc.8; Under &os; - In 2002 &os; integrated the NetBSD rc.d - system for system initialization. Users should notice the files - listed in the /etc/rc.d - directory. Many of these files are for basic services which can - be controlled with the , - , and options. - For instance, &man.sshd.8; can be restarted with the following - command: + In 2002, &os; integrated the NetBSD &man.rc.8; system for + system initialization. The files listed in /etc/rc.d provide basic services + which can be controlled with the , + , and options + to &man.service.8;. For instance, &man.sshd.8; can be restarted + with the following command: &prompt.root; service sshd restart - This procedure is similar for other services. Of course, - services are usually started automatically at boot time as - specified in &man.rc.conf.5;. For example, enabling the Network - Address Translation daemon at startup is as simple as adding the - following line to /etc/rc.conf: + This procedure can be used to start services on a running + system. Services will be started automatically at boot time + as specified in &man.rc.conf.5;. For example, to enable + &man.natd.8; at system startup, add the following line to + /etc/rc.conf: natd_enable="YES" If a line is already - present, then simply change the to - . The rc scripts will automatically load - any other dependent services during the next reboot, as - described below. - - Since the rc.d system is primarily - intended to start/stop services at system startup/shutdown time, - the standard , and + present, change the NO to + YES. The &man.rc.8; scripts will + automatically load any dependent services during the next boot, + as described below. + + Since the &man.rc.8; system is primarily intended to start + and stop services at system startup and shutdown time, the + , and options will only perform their action - if the appropriate /etc/rc.conf variables - are set. For instance, sshd restart will + if the appropriate /etc/rc.conf variable + is set. For instance, sshd restart will only work if sshd_enable is set to in /etc/rc.conf. To , or - a service regardless of the settings in - /etc/rc.conf, the commands should be + a service regardless of the settings + in /etc/rc.conf, these commands should be prefixed with one. For instance, to restart - sshd regardless of the current + &man.sshd.8; regardless of the current /etc/rc.conf setting, execute the following command: &prompt.root; service sshd onerestart - It is easy to check if a service is enabled in - /etc/rc.conf by running the appropriate - rc.d script with the option - . Thus, an administrator can check that - sshd is in fact enabled in - /etc/rc.conf by running: + To check if a service is enabled in + /etc/rc.conf, run the appropriate + &man.rc.8; script with . This example + checks to see if &man.sshd.8; is enabled in + /etc/rc.conf: &prompt.root; service sshd rcvar # sshd $sshd_enable=YES - The second line (# sshd) is the output - from sshd, not a - root console. + The # sshd line is output from the + above command, not a root console. To determine whether or not a service is running, use . For instance, to verify that - sshd is running: + &man.sshd.8; is running: &prompt.root; service sshd status sshd is running as pid 433. - In some cases it is also possible to - a service. This will attempt to send a signal to an individual - service, forcing the service to reload its configuration files. - In most cases this means sending the service a - SIGHUP signal. Support for this feature is - not included for every service. + In some cases, it is also possible to + a service. This attempts to send a + signal to an individual service, forcing the service to reload + its configuration files. In most cases, this means sending + the service a SIGHUP signal. Support for + this feature is not included for every service. - The rc.d system is not only used for - network services, it also contributes to most of the system - initialization. For instance, when the - bgfsck script is executed, it will print - out the following message: + The &man.rc.8; system is used for network services and it + also contributes to most of the system initialization. For + instance, when the + /etc/rc.d/bgfsck script is executed, it + prints out the following message: Starting background file system checks in 60 seconds. - Therefore this file is used for background file system - checks, which are done only during system initialization. + This script is used for background file system checks, + which occur only during system initialization. Many system services depend on other services to function - properly. For example, NIS and other RPC-based services may - fail to start until after the rpcbind - (portmapper) service has started. To resolve this issue, - information about dependencies and other meta-data is included - in the comments at the top of each startup script. The - &man.rcorder.8; program is then used to parse these comments + properly. For example, &man.yp.8; and other + RPC-based services may fail to start until + after the &man.rpcbind.8; service has started. To resolve this + issue, information about dependencies and other meta-data is + included in the comments at the top of each startup script. + The &man.rcorder.8; program is used to parse these comments during system initialization to determine the order in which system services should be invoked to satisfy the dependencies. - The following words must be included in all startup scripts - (they are required by &man.rc.subr.8; to enable - the startup script): + The following key word must be included in all startup + scripts as it is required by &man.rc.subr.8; to + enable the startup script: PROVIDE: Specifies the services this file provides. - The following words may be included at the top of each - startup file. They are not strictly necessary, but they are + The following key words may be included at the top of each + startup script. They are not strictly necessary, but are useful as hints to &man.rcorder.8;: REQUIRE: Lists services which are - required for this service. This file will run - after the specified services. + required for this service. The script containing this key + word will run after the specified + services. BEFORE: Lists services which depend - on this service. This file will run - before the specified services. + on this service. The script containing this key word will + run before the specified + services. By carefully setting these keywords for each startup script, - an administrator has a very fine-grained level of control of the - startup order of the scripts, without the hassle of - runlevels like some other &unix; operating + an administrator has a fine-grained level of control of the + startup order of the scripts, without the need for + runlevels used by some &unix; operating systems. - Additional information about the rc.d - system can be found in &man.rc.8; and &man.rc.subr.8;. Refer to - this article for - instructions on how to create custom rc.d + Additional information can be found in &man.rc.8; and + &man.rc.subr.8;. Refer to this article for + instructions on how to create custom &man.rc.8; scripts. Marc Fonvieille Contributed by Setting Up Network Interface Cards network cards configuration - Adding and configuring a network card is a common task for - any &os; administrator. + Adding and configuring a network interface card + (NIC) is a common task for any &os; + administrator. Locating the Correct Driver network cards driver - First, determine the model of the network interface card - and the chip it uses. &os; supports a wide variety of network - interface cards. Check the Hardware Compatibility List for - the &os; release to see if the card is supported. + First, determine the model of the NIC + and the chip it uses. &os; supports a wide variety of + NICs. Check the Hardware Compatibility + List for the &os; release to see if the NIC + is supported. - If the card is supported, determine the name of the &os; - driver for the card. Refer to - /usr/src/sys/conf/NOTES and + If the NIC is supported, determine + the name of the &os; driver for the NIC. + Refer to /usr/src/sys/conf/NOTES and /usr/src/sys/arch/conf/NOTES - for the list of network interface drivers with some + for the list of NIC drivers with some information about the supported chipsets. When in doubt, read the manual page of the driver as it will provide more information about the supported hardware and any known limitations of the driver. - The drivers for common network cards are already present - in the GENERIC kernel, meaning the card - should show up during boot, as in this example: + The drivers for common NICs are + already present in the GENERIC kernel, + meaning the NIC should show up during boot. + In this example, two NICs using the + &man.dc.4; driver are present on the system: dc0: <82c169 PNIC 10/100BaseTX> port 0xa000-0xa0ff mem 0xd3800000-0xd38 000ff irq 15 at device 11.0 on pci0 miibus0: <MII bus> on dc0 bmtphy0: <BCM5201 10/100baseTX PHY> PHY 1 on miibus0 bmtphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc0: Ethernet address: 00:a0:cc:da:da:da dc0: [ITHREAD] dc1: <82c169 PNIC 10/100BaseTX> port 0x9800-0x98ff mem 0xd3000000-0xd30 000ff irq 11 at device 12.0 on pci0 miibus1: <MII bus> on dc1 bmtphy1: <BCM5201 10/100baseTX PHY> PHY 1 on miibus1 bmtphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc1: Ethernet address: 00:a0:cc:da:da:db dc1: [ITHREAD] - In this example, two cards using the &man.dc.4; driver are - present on the system. - - If the driver for the interface is not present in - GENERIC, but a driver is available, the - driver will need to be loaded before the interface can be - configured and used. This may be accomplished in one of two - ways: + If the driver for the NIC is not + present in GENERIC, but a driver is + available, the driver will need to be loaded before the + NIC can be configured and used. This may + be accomplished in one of two ways: The easiest way is to load a kernel module for the - network card with &man.kldload.8;. To also automatically - load the driver at boot time, add the appropriate line to - /boot/loader.conf. Not all NIC - drivers are available as modules; notable examples of - devices for which modules do not exist are ISA - cards. + NIC using &man.kldload.8;. To also + automatically load the driver at boot time, add the + appropriate line to + /boot/loader.conf. Not all + NIC drivers are available as + modules. - Alternatively, statically compile support for the card - into a custom kernel. Refer to + Alternatively, statically compile support for the + NIC into a custom kernel. Refer to /usr/src/sys/conf/NOTES, /usr/src/sys/arch/conf/NOTES and the manual page of the driver to determine which line to add to the custom kernel configuration file. For more - information about recompiling the kernel, refer to - . If the card was detected - at boot, the kernel does not need to be recompiled. + information about recompiling the kernel, refer to . If the + NIC was detected at boot, the kernel + does not need to be recompiled. - Using &windows; NDIS Drivers + Using &windows; <acronym>NDIS</acronym> Drivers - NDIS + NDIS NDISulator &windows; drivers - Microsoft Windows - - Microsoft Windows + µsoft.windows; device drivers - KLD (kernel loadable object) + KLD (kernel loadable + object) Unfortunately, there are still many vendors that do not provide schematics for their drivers to the open source community because they regard such information as trade secrets. Consequently, the developers of &os; and other - operating systems are left two choices: develop the drivers - by a long and pain-staking process of reverse engineering or - using the existing driver binaries available for the - µsoft.windows; platforms. Most developers, including - those involved with &os;, have taken the latter - approach. - - Thanks to the contributions of Bill Paul (wpaul) there - is native support for the Network Driver - Interface Specification (NDIS). The &os; NDISulator - (otherwise known as Project Evil) takes a &windows; driver - binary and basically tricks it into thinking it is running - on &windows;. Because the &man.ndis.4; driver is using a - &windows; binary, it only runs on &i386; and amd64 systems. - PCI, CardBus, PCMCIA (PC-Card), and USB devices are - supported. - - To use the NDISulator, three things are needed: + operating systems are left with two choices: develop the + drivers by a long and pain-staking process of reverse + engineering or using the existing driver binaries available + for µsoft.windows; platforms. + + &os; provides native support for the + Network Driver Interface Specification + (NDIS). It includes &man.ndisgen.8; + which can be used to convert a &windowsxp; driver into a + format that can be used on &os;. Because the &man.ndis.4; + driver uses a &windowsxp; binary, it only runs on &i386; + and amd64 systems. PCI, CardBus, + PCMCIA, and USB + devices are supported. + + To use &man.ndisgen.8;, three things are needed: - Kernel sources + &os; kernel sources. - &windowsxp; driver binary - (.SYS extension) + A &windowsxp; driver binary with a + .SYS extension. - &windowsxp; driver configuration file - (.INF extension) + A &windowsxp; driver configuration file with a + .INF extension. - Locate the files for the specific card. Generally, - they can be found on the included CDs or at the vendor's - website. The following examples use - W32DRIVER.SYS and + Download the .SYS and + .INF files for the specific + NIC. Generally, these can be found on + the driver CD or at the vendor's website. The following + examples use W32DRIVER.SYS and W32DRIVER.INF. The driver bit width must match the version of &os;. For &os;/i386, use a &windows; 32-bit driver. For &os;/amd64, a &windows; 64-bit driver is needed. The next step is to compile the driver binary into a loadable kernel module. As root, use &man.ndisgen.8;: &prompt.root; ndisgen /path/to/W32DRIVER.INF /path/to/W32DRIVER.SYS - &man.ndisgen.8; is interactive and prompts for any extra - information it requires. A new kernel module is written in - the current directory. Use &man.kldload.8; to load the new - module: + This command is interactive and prompts for any extra + information it requires. A new kernel module will be + generated in the current directory. Use &man.kldload.8; + to load the new module: &prompt.root; kldload ./W32DRIVER_SYS.ko In addition to the generated kernel module, the ndis.ko and if_ndis.ko modules must be loaded. This should happen automatically when any module that depends on &man.ndis.4; is loaded. If not, load them manually, using the following commands: &prompt.root; kldload ndis &prompt.root; kldload if_ndis - The first command loads the NDIS miniport driver - wrapper, the second loads the actual network - interface. + The first command loads the &man.ndis.4; miniport driver + wrapper and the second loads the generated + NIC driver. - Now, check &man.dmesg.8; to see if there were any errors - loading. If all went well, the output should be similar to + Check &man.dmesg.8; to see if there were any load + errors. If all went well, the output should be similar to the following: ndis0: <Wireless-G PCI Adapter> mem 0xf4100000-0xf4101fff irq 3 at device 8.0 on pci1 ndis0: NDIS API version: 5.0 ndis0: Ethernet address: 0a:b1:2c:d3:4e:f5 ndis0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps ndis0: 11g rates: 6Mbps 9Mbps 12Mbps 18Mbps 36Mbps 48Mbps 54Mbps - From here you can treat the - ndis0 device like any other network - interface (e.g., dc0). + From here, ndis0 can be + configured like any other NIC. - To configure the system to load the NDIS modules at - boot time, copy the generated module, - W32DRIVER_SYS.ko, to the /boot/modules directory. Then, - add the following line to + To configure the system to load the &man.ndis.4; modules + at boot time, copy the generated module, + W32DRIVER_SYS.ko, to /boot/modules. Then, add the + following line to /boot/loader.conf: W32DRIVER_SYS_load="YES" Configuring the Network Card network cards configuration - Once the right driver is loaded for the network card, the - card needs to be configured. As with many other things, the - network card may have been configured at installation time by - sysinstall. + Once the right driver is loaded for the + NIC, the card needs to be configured. It + may have been configured at installation time by + &man.sysinstall.8;. - To display the configuration for the network interfaces, + To display the NIC configuration, enter the following command: &prompt.user; ifconfig dc0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=80008<VLAN_MTU,LINKSTATE> ether 00:a0:cc:da:da:da inet 192.168.1.3 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet autoselect (100baseTX <full-duplex>) status: active dc1: flags=8802<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=80008<VLAN_MTU,LINKSTATE> ether 00:a0:cc:da:da:db inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255 media: Ethernet 10baseT/UTP status: no carrier lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384 options=3<RXCSUM,TXCSUM> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 nd6 options=3<PERFORMNUD,ACCEPT_RTADV> In this example, the following devices were displayed: dc0: The first Ethernet - interface + interface. dc1: The second Ethernet - interface + interface. lo0: The loopback - device + device. &os; uses the driver name followed by the order in which - one the card is detected at the kernel boot to name the - network card. For example sis2 would - be the third network card on the system using the &man.sis.4; + the card is detected at boot to name the + NIC. For example, + sis2 is the third + NIC on the system using the &man.sis.4; driver. - In this example, the dc0 device - is up and running. The key indicators are: + In this example, dc0 is up and + running. The key indicators are: UP means that the card is configured and ready. The card has an Internet (inet) - address (in this case - 192.168.1.3). + address, 192.168.1.3. It has a valid subnet mask - (netmask; - 0xffffff00 is the same as - 255.255.255.0). + (netmask), where 0xffffff00 is the same as + 255.255.255.0. - It has a valid broadcast address (in this case, - 192.168.1.255). + It has a valid broadcast address, 192.168.1.255. - The MAC address of the card (ether) - is 00:a0:cc:da:da:da + The MAC address of the card + (ether) is 00:a0:cc:da:da:da. The physical media selection is on autoselection mode (media: Ethernet autoselect (100baseTX <full-duplex>)). In this example, - dc1 was configured to run with + dc1 is configured to run with 10baseT/UTP media. For more information on available media types for a driver, refer to its manual page. The status of the link (status) is active, indicating that the carrier signal is detected. For dc1, the status: no carrier status is normal when an Ethernet cable is not plugged into the card. If the &man.ifconfig.8; output had shown something similar to: dc0: flags=8843<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=80008<VLAN_MTU,LINKSTATE> ether 00:a0:cc:da:da:da media: Ethernet autoselect (100baseTX <full-duplex>) status: active it would indicate the card has not been configured. - To configure the card, you will need - root privileges. The network card - configuration can be performed from the command line with - &man.ifconfig.8; but will not persist after a reboot unless - the network card's configuration is also added to - /etc/rc.conf using an editor. Add a - line for each network card present on the system, as seen in + The card must be configured as root. + The NIC configuration can be performed + from the command line with &man.ifconfig.8; but will not + persist after a reboot unless the configuration is also added + to /etc/rc.conf. Add a line for each + NIC present on the system, as seen in this example: ifconfig_dc0="inet 192.168.1.3 netmask 255.255.255.0" ifconfig_dc1="inet 10.0.0.1 netmask 255.255.255.0 media 10baseT/UTP" Replace dc0 and - dc1 and the IP address information - with the correct values for the system. - Refer to the man page for the driver, &man.ifconfig.8; and + dc1 and the IP + address information with the correct values for the system. + Refer to the man page for the driver, &man.ifconfig.8;, and &man.rc.conf.5; for more details about the allowed options and the syntax of /etc/rc.conf. If the network was configured during installation, some - lines about the network card(s) may be already present. - Double check /etc/rc.conf before adding - any lines. - - If the network is not using DNS, edit - /etc/hosts to add the names and the IP - addresses of various machines of the LAN, if they are not - already there. For more information, refer to &man.hosts.5; - and to + entries for the NIC(s) may be already + present. Double check /etc/rc.conf + before adding any lines. + + If the network is not using DNS, edit + /etc/hosts to add the names and + IP addresses of of the hosts on the + LAN, if they are not already there. For + more information, refer to &man.hosts.5; and to /usr/share/examples/etc/hosts. - If there is no DHCP server and access to the Internet is - needed, manually configure the default gateway and the - nameserver: + If there is no DHCP server and + access to the Internet is needed, manually configure the + default gateway and the nameserver: &prompt.root; echo 'defaultrouter="your_default_router"' >> /etc/rc.conf &prompt.root; echo 'nameserver your_DNS_server' >> /etc/resolv.conf Testing and Troubleshooting - Once the necessary changes in + Once the necessary changes to /etc/rc.conf are saved, a reboot can be used to test the network configuration and to verify that the system restarts without any configuration errors. Alternatively, apply the settings to the networking system with this command: &prompt.root; service netif restart If a default gateway has been set in - /etc/rc.conf, use also this + /etc/rc.conf, also issue this command: &prompt.root; service routing restart Once the networking system has been relaunched, test the - network interfaces. + NICs. Testing the Ethernet Card network cards testing To verify that an Ethernet card is configured correctly, - ping the interface itself, and then ping another machine on - the LAN: + &man.ping.8; the interface itself, and then &man.ping.8; + another machine on the LAN: &prompt.user; ping -c5 192.168.1.3 PING 192.168.1.3 (192.168.1.3): 56 data bytes 64 bytes from 192.168.1.3: icmp_seq=0 ttl=64 time=0.082 ms 64 bytes from 192.168.1.3: icmp_seq=1 ttl=64 time=0.074 ms 64 bytes from 192.168.1.3: icmp_seq=2 ttl=64 time=0.076 ms 64 bytes from 192.168.1.3: icmp_seq=3 ttl=64 time=0.108 ms 64 bytes from 192.168.1.3: icmp_seq=4 ttl=64 time=0.076 ms --- 192.168.1.3 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.074/0.083/0.108/0.013 ms &prompt.user; ping -c5 192.168.1.2 PING 192.168.1.2 (192.168.1.2): 56 data bytes 64 bytes from 192.168.1.2: icmp_seq=0 ttl=64 time=0.726 ms 64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=0.766 ms 64 bytes from 192.168.1.2: icmp_seq=2 ttl=64 time=0.700 ms 64 bytes from 192.168.1.2: icmp_seq=3 ttl=64 time=0.747 ms 64 bytes from 192.168.1.2: icmp_seq=4 ttl=64 time=0.704 ms --- 192.168.1.2 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.700/0.729/0.766/0.025 ms - To test network resolution, use the machine name instead - of 192.168.1.2. If there is - no DNS server on the network, + To test network resolution, use the host name instead + of the IP address. If there is no + DNS server on the network, /etc/hosts must first be configured. Troubleshooting network cards troubleshooting - Troubleshooting hardware and software configurations is - always a pain, and a pain which can be alleviated by - checking the simple things first. Is the network cable - plugged in? Are the network services properly configured? - Is the firewall configured correctly? Is the network card - supported by &os;? Always before sending a bug report, - check the hardware notes, update the version of &os; to the - latest STABLE version, check the mailing list archives, and - search the Internet. - - If the card works, yet performance is poor, it would be - worthwhile to read over the &man.tuning.7; manual page. - Also, check the network configuration as incorrect network - settings can cause slow connections. + When troubleshooting hardware and software + configurations, check the simple things first. Is the + network cable plugged in? Are the network services properly + configured? Is the firewall configured correctly? Is the + NIC supported by &os;? Before sending + a bug report, always check the Hardware Notes, update the + version of &os; to the latest STABLE version, check the + mailing list archives, and search the Internet. + + If the card works, yet performance is poor, read + through &man.tuning.7;. Also, check the network + configuration as incorrect network settings can cause slow + connections. Some users experience one or two device timeout messages, which is normal for some cards. If they continue, or are bothersome, determine if the device is conflicting with another device. Double check the cable connections. Consider trying another card. - At times, users see a few - watchdog timeout errors. The first - thing to do is to check the network cable. Many cards - require a PCI slot which supports Bus Mastering. On some - old motherboards, only one PCI slot allows it (usually slot - 0). Check the network card and the motherboard + To resolve watchdog timeout + errors, first check the network cable. Many cards + require a PCI slot which supports bus + mastering. On some old motherboards, only one + PCI slot allows it, usually slot 0. + Check the NIC and the motherboard documentation to determine if that may be the problem. No route to host messages occur if the system is unable to route a packet to the destination - host. This can happen if no default route is specified, or + host. This can happen if no default route is specified or if a cable is unplugged. Check the output of netstat -rn and make sure there is a - valid route to the host. If there is not, read on to - . + valid route to the host. If there is not, read . ping: sendto: Permission denied error messages are often caused by a misconfigured firewall. - If ipfw is enabled in the kernel but no - rules have been defined, then the default policy is to deny - all traffic, even ping requests! Read on to - for more information. + If a firewall is enabled on &os; but no rules have been + defined, the default policy is to deny all traffic, even + &man.ping.8;. Refer to for more information. - Sometimes performance of the card is poor, or below - average. In these cases it is best to set the media + Sometimes performance of the card is poor or below + average. In these cases, try setting the media selection mode from autoselect to the - correct media selection. While this usually works for most - hardware, it may not resolve this issue for everyone. - Again, check all the network settings, and read over the - &man.tuning.7; manual page. + correct media selection. While this works for most + hardware, it may or may not resolve the issue. Again, + check all the network settings, and refer to + &man.tuning.7;. Virtual Hosts virtual hosts - IP aliases + IP + aliases - A very common use of &os; is virtual site hosting, where one + A common use of &os; is virtual site hosting, where one server appears to the network as many servers. This is achieved by assigning multiple network addresses to a single interface. A given network interface has one real address, and may have any number of alias addresses. These aliases are normally added by placing alias - entries in /etc/rc.conf. - - An alias entry for the interface - fxp0 looks like: + entries in /etc/rc.conf, as seen in this + example: ifconfig_fxp0_alias0="inet xxx.xxx.xxx.xxx netmask xxx.xxx.xxx.xxx" - Note that alias entries must start with - alias0 and proceed upwards in order, (for - example, _alias1, _alias2, - and so on). The configuration process will stop at the first + Alias entries must start with + alias0 using a + sequential number such as + alias0, alias1, + and so on. The configuration process will stop at the first missing number. - The calculation of alias netmasks is important, but - fortunately quite simple. For a given interface, there must be - one address which correctly represents the network's netmask. - Any other addresses which fall within this network must have a - netmask of all 1s (expressed as either - 255.255.255.255 or - 0xffffffff). + The calculation of alias netmasks is important. For a + given interface, there must be one address which correctly + represents the network's netmask. Any other addresses which + fall within this network must have a netmask of all + 1s, expressed as either 255.255.255.255 or 0xffffffff. For example, consider the case where the fxp0 interface is connected to two - networks: the 10.1.1.0 network - with a netmask of 255.255.255.0 - and the 202.0.75.16 network with - a netmask of 255.255.255.240. - The system is to be configured to appear in the - range - 10.1.1.1 through - 10.1.1.5 and - 202.0.75.17 through - 202.0.75.20. Only the first - address in a given network range should have a real - netmask. All the rest (10.1.1.2 - through 10.1.1.5 and - 202.0.75.18 through - 202.0.75.20) must be configured - with a netmask of - 255.255.255.255. + networks: 10.1.1.0 with a + netmask of 255.255.255.0 and + 202.0.75.16 with a netmask of + 255.255.255.240. The system + is to be configured to appear in the ranges 10.1.1.1 through 10.1.1.5 and 202.0.75.17 through 202.0.75.20. Only the first address + in a given network range should have a real netmask. All the + rest (10.1.1.2 through 10.1.1.5 and 202.0.75.18 through 202.0.75.20) must be configured with + a netmask of 255.255.255.255. The following /etc/rc.conf entries - configure the adapter correctly for this arrangement: + configure the adapter correctly for this scenario: ifconfig_fxp0="inet 10.1.1.1 netmask 255.255.255.0" ifconfig_fxp0_alias0="inet 10.1.1.2 netmask 255.255.255.255" ifconfig_fxp0_alias1="inet 10.1.1.3 netmask 255.255.255.255" ifconfig_fxp0_alias2="inet 10.1.1.4 netmask 255.255.255.255" ifconfig_fxp0_alias3="inet 10.1.1.5 netmask 255.255.255.255" ifconfig_fxp0_alias4="inet 202.0.75.17 netmask 255.255.255.240" ifconfig_fxp0_alias5="inet 202.0.75.18 netmask 255.255.255.255" ifconfig_fxp0_alias6="inet 202.0.75.19 netmask 255.255.255.255" ifconfig_fxp0_alias7="inet 202.0.75.20 netmask 255.255.255.255" Niclas Zeising Contributed by Configuring the System Logger, - <application>syslogd</application> + syslogd system logging syslog - syslogd + &man.syslogd.8; System logging is an important aspect of system - administration. It is used both to detect hardware and software - issues and errors in the system. It also plays a very - important role in security auditing and incident response. - System daemons without a controlling terminal also usually log - information to a system logging facility or other log - file. + administration. It is used to detect hardware and software + issues and errors in the system. It plays an important role + in security auditing and incident response. System daemons + without a controlling terminal usually log information to a + system logging facility or other log file. This section describes how to configure and use the &os; system logger, &man.syslogd.8;, and how to perform log rotation - and log management using &man.newsyslog.8;. Focus - will be on setting up and using syslogd on - a local machine. For more advanced setups using a separate - loghost, see . + and log management using &man.newsyslog.8;. Focus will be on + setting up and using &man.syslogd.8; on a local machine. For + more advanced setups using a separate loghost, see . - Using <application>syslogd</application> + Using <command>syslogd</command> - In the default &os; configuration &man.syslogd.8; is + In the default &os; configuration, &man.syslogd.8; is started at boot. This is controlled by the variable syslogd_enable in /etc/rc.conf. There are numerous application arguments that affect the behavior of &man.syslogd.8;. To change them, use syslogd_flags in /etc/rc.conf. Refer to &man.syslogd.8; for more information on the arguments, and &man.rc.conf.5;, and for more information about /etc/rc.conf and the &man.rc.8; subsystem. - Configuring <application>syslogd</application> + Configuring <command>syslogd</command> syslog.conf The configuration file, by default /etc/syslog.conf, controls what &man.syslogd.8; does with the log entries once they are received. There are several parameters to control the handling of incoming events, of which the most basic are facility and level. The facility describes which subsystem generated the message, such as the kernel or a daemon, and the level describes the severity of the event that occurred. This makes it possible to log the message to different log files, or discard it, depending on the facility and level. It is also possible to take action depending on the application that sent the message, and in the case of - remote logging, also the hostname of the machine generating + remote logging, the hostname of the machine generating the logging event. - Configuring &man.syslogd.8; is quite straight - forward. The configuration file contains one line per action, - and the syntax for each line is a selector field followed by - an action field. The syntax of the selector field is - facility.level which will match - log messages from facility at level - level or higher. It is also - possible to add an optional comparison flag before the level - to specify more precisely what is logged. Multiple + The configuration file for &man.syslogd.8; contains one + line per action, and the syntax for each line is a selector + field followed by an action field. The syntax of the selector + field is facility.level which will + match log messages from facility + at level level or higher. It is + also possible to add an optional comparison flag before the + level to specify more precisely what is logged. Multiple selector fields can be used for the same action, and are separated with a semicolon (;). Using - * will match everything. - The action field denotes where to send the log message, - such as a file or a remote log host. As an example, here is - the default syslog.conf from &os;: + * will match everything. The action field + denotes where to send the log message, such as to a file or + remote log host. As an example, here is the default + syslog.conf from &os;: # $&os;$ # # Spaces ARE valid field separators in this file. However, # other *nix-like systems still insist on using tabs as field # separators. If you are sharing this file between systems, you # may want to use only tabs as field separators here. -# Consult the &man.syslog.conf.5; manpage. +# Consult the syslog.conf(5) manpage. *.err;kern.warning;auth.notice;mail.crit /dev/console *.notice;authpriv.none;kern.debug;lpr.info;mail.crit;news.err /var/log/messages security.* /var/log/security auth.info;authpriv.info /var/log/auth.log mail.info /var/log/maillog lpr.info /var/log/lpd-errs ftp.info /var/log/xferlog cron.* /var/log/cron *.=debug /var/log/debug.log *.emerg * # uncomment this to log all writes to /dev/console to /var/log/console.log #console.info /var/log/console.log # uncomment this to enable logging of all log messages to /var/log/all.log # touch /var/log/all.log and chmod it to mode 600 before it will work #*.* /var/log/all.log # uncomment this to enable logging to a remote loghost named loghost #*.* @loghost # uncomment these if you're running inn # news.crit /var/log/news/news.crit # news.err /var/log/news/news.err # news.notice /var/log/news/news.notice !ppp *.* /var/log/ppp.log !* Match all messages with a level of err or higher, as well as kern.warning, auth.notice and mail.crit, and send these log messages - to the console (/dev/console). + to the console + (/dev/console). Match all messages from the mail facility at level info or above, and log the messages to /var/log/maillog. This line uses a comparison flag, = to only match messages at level debug, and log them in /var/log/debug.log. - Here is an example usage of a - program specification. This will - make the rules following only be valid for the program - in the program specification. In this case - this line and the following makes all messages from - ppp, but no other programs, end up in + Here is an example usage of a program + specification. This makes the rules + following it only valid for the program in the program + specification. In this case, this and the following + lines log all messages from &man.ppp.8;, but no other + programs, to /var/log/ppp.log. This example shows that there are plenty of levels and subsystems. The levels are, in order from most to least critical: emerg, alert, crit, err, warning, notice, - info and debug. + info, and debug. The facilities are, in no particular order: auth, authpriv, console, cron, daemon, ftp, kern, lpr, mail, mark, news, security, syslog, user, - uucp and local0 through + uucp, and local0 through local7. Be aware that other operating systems might have different facilities. - With this knowledge it is easy to add a new line to + With this knowledge, it is easy to add a new line to /etc/syslog.conf to log everything from the different daemons on level notice and higher to /var/log/daemon.log. Just add the following: daemon.notice /var/log/daemon.log For more information about the different levels and facilities, refer to &man.syslog.3; and &man.syslogd.8;. - For more information about syslog.conf, - its syntax, and more advanced usage examples, see - &man.syslog.conf.5; and - . + For more information about + /etc/syslog.conf, its syntax, and more + advanced usage examples, see &man.syslog.conf.5; and . Log Management and Rotation with - <application>newsyslog</application> + newsyslog newsyslog newsyslog.conf log rotation log management Log files tend to grow quickly and accumulate steadily. This leads to the files being full of less immediately useful information while filling up the hard drive. Log management attempts to mitigate this. In &os;, &man.newsyslog.8; is used to manage log files. This program periodically rotates and compresses log files, and optionally creates missing log files and signals programs when log files are moved. The log files - are not necessarily generated by syslog as &man.newsyslog.8; - works with any logs written from any program. Note that - newsyslog is normally run from - &man.cron.8; and is not a system daemon. In the default + are not necessarily generated by &man.syslogd.8; as + &man.newsyslog.8; works with any logs written from any + program. While &man.newsyslog.8; is normally run from + &man.cron.8;, it is not a system daemon. In the default configuration, it is run every hour. Configuring - <application>newsyslog</application> + newsyslog - To know what actions to take, &man.newsyslog.8; reads + To know which actions to take, &man.newsyslog.8; reads its configuration file, by default /etc/newsyslog.conf. This configuration file contains one line for each file that &man.newsyslog.8; manages. Each line states the file owner, permissions, when to rotate that file, optional flags that affect log rotation, such as compression, and programs to signal when the log is rotated. Here is the default configuration in &os;: # configuration file for newsyslog -# $&os;$ +# $FreeBSD$ # # Entries which do not specify the '/pid_file' field will cause the # syslogd process to be signalled when that log file is rotated. This # action is only appropriate for log files which are written to by the # syslogd process (ie, files listed in /etc/syslog.conf). If there # is no process which needs to be signalled when a given log file is # rotated, then the entry for that file should include the 'N' flag. # # The 'flags' field is one or more of the letters: BCDGJNUXZ or a '-'. # # Note: some sites will want to select more restrictive protections than the # defaults. In particular, it may be desirable to switch many of the 644 # entries to 640 or 600. For example, some sites will consider the # contents of maillog, messages, and lpd-errs to be confidential. In the # future, these defaults may change to more conservative ones. # # logfilename [owner:group] mode count size when flags [/pid_file] [sig_num] /var/log/all.log 600 7 * @T00 J /var/log/amd.log 644 7 100 * J /var/log/auth.log 600 7 100 @0101T JC /var/log/console.log 600 5 100 * J /var/log/cron 600 3 100 * JC /var/log/daily.log 640 7 * @T00 JN /var/log/debug.log 600 7 100 * JC -/var/log/init.log 644 3 100 * J /var/log/kerberos.log 600 7 100 * J /var/log/lpd-errs 644 7 100 * JC /var/log/maillog 640 7 * @T00 JC /var/log/messages 644 5 100 @0101T JC /var/log/monthly.log 640 12 * $M1D0 JN /var/log/pflog 600 3 100 * JB /var/run/pflogd.pid /var/log/ppp.log root:network 640 3 100 * JC /var/log/security 600 10 100 * JC /var/log/sendmail.st 640 10 * 168 B /var/log/utx.log 644 3 * @01T05 B /var/log/weekly.log 640 5 1 $W6D0 JN /var/log/xferlog 600 7 100 * JC Each line starts with the name of the file to be - rotated, optionally followed by an owner - and group for both rotated and newly created files. - The next field, mode is the mode of the - files and count denotes how many rotated - log files should be kept. The size and - when fields tell - newsyslog when to rotate the file. - A log file is rotated when either its size is larger than - the size field, or when the time in the + rotated, optionally followed by an owner and group for both + rotated and newly created files. The + mode field sets the permissions on the + log file and count denotes how many + rotated log files should be kept. The + size and when fields + tell &man.newsyslog.8; when to rotate the file. A log + file is rotated when either its size is larger than the + size field, or when the time in the when filed has passed. * means that this field is ignored. The flags field gives - &man.newsyslog.8; further instructions, such as - how to compress the rotated file, or to create the log file - if it is missing. The last two fields are optional, and + &man.newsyslog.8; further instructions, such as how to + compress the rotated file or to create the log file if it + is missing. The last two fields are optional, and specify the PID-file of a - process and a signal number to send to that process with - when the file is rotated. For more information on all - fields, valid flags and how to specify the rotation time, - refer to &man.newsyslog.conf.5;. Remember that - newsyslog is run from - cron and can not rotate files more - often than it is run from &man.cron.8;. + role="Process Identifier">PID file of a process + and a signal number to send to that process when the file + is rotated. For more information on all fields, valid + flags, and how to specify the rotation time, refer to + &man.newsyslog.conf.5;. Since &man.newsyslog.8; is run + from &man.cron.8;, it can not rotate files more often than + it is run from &man.cron.8;. Configuration Files <filename class="directory">/etc</filename> Layout There are a number of directories in which configuration information is kept. These include: /etc - Generic system configuration information; data - here is system-specific. + Generic system-specific configuration + information. /etc/defaults Default versions of system configuration files. /etc/mail - Extra &man.sendmail.8; configuration, other - MTA configuration files. + Extra &man.sendmail.8; configuration and other + MTA configuration files. /etc/ppp Configuration for both user- and kernel-ppp programs. /etc/namedb Default location for &man.named.8; data. Normally named.conf and zone files are stored here. /usr/local/etc Configuration files for installed applications. May contain per-application subdirectories. /usr/local/etc/rc.d - Start/stop scripts for installed + &man.rc.8; scripts for installed applications. /var/db Automatically generated system-specific database - files, such as the package database, the locate - database, and so on + files, such as the package database and the + &man.locate.1; database. Hostnames hostname DNS <filename>/etc/resolv.conf</filename> resolv.conf - /etc/resolv.conf dictates how - &os;'s resolver accesses the Internet Domain Name System - (DNS). + How a + &os; system accesses the Internet Domain Name System + (DNS) is controlled by + &man.resolv.conf.5;. The most common entries to - resolv.conf are: + /etc/resolv.conf are: nameserver - The IP address of a name server the resolver - should query. The servers are queried in the order - listed with a maximum of three. + The IP address of a name + server the resolver should query. The servers are + queried in the order listed with a maximum of + three. search Search list for hostname lookup. This is normally determined by the domain of the local hostname. domain The local domain name. - A typical resolv.conf: + A typical /etc/resolv.conf looks + like this: search example.com nameserver 147.11.1.11 nameserver 147.11.100.30 Only one of the search and domain options should be used. - When using DHCP, &man.dhclient.8; usually rewrites - resolv.conf with information received - from the DHCP server. + When using DHCP, &man.dhclient.8; + usually rewrites /etc/resolv.conf + with information received from the DHCP + server. <filename>/etc/hosts</filename> hosts /etc/hosts is a simple text - database reminiscent of the old Internet. It works in - conjunction with DNS and NIS providing name to IP address - mappings. Local computers connected via a LAN can be placed - in here for simplistic naming purposes instead of setting up - a &man.named.8; server. Additionally, + database which works in conjunction with + DNS and + NIS to provide host name to + IP address mappings. Entries for local + computers connected via a LAN can be + added to this file for simplistic naming purposes instead + of setting up a &man.named.8; server. Additionally, /etc/hosts can be used to provide a local record of Internet names, reducing the need to query - externally for commonly accessed names. + external DNS servers for commonly + accessed names. # $&os;$ # # # Host Database # # This file should contain the addresses and aliases for local hosts that # share this file. Replace 'my.domain' below with the domainname of your # machine. # # In the presence of the domain name service or NIS, this file may # not be consulted at all; see /etc/nsswitch.conf for the resolution order. # # ::1 localhost localhost.my.domain 127.0.0.1 localhost localhost.my.domain # # Imaginary network. #10.0.0.2 myname.my.domain myname #10.0.0.3 myfriend.my.domain myfriend # # According to RFC 1918, you can use the following IP networks for # private nets which will never be connected to the Internet: # # 10.0.0.0 - 10.255.255.255 # 172.16.0.0 - 172.31.255.255 # 192.168.0.0 - 192.168.255.255 # # In case you want to be able to connect to the Internet, you need # real official assigned numbers. Do not try to invent your own network # numbers but instead get one from your network provider (if any) or # from your regional registry (ARIN, APNIC, LACNIC, RIPE NCC, or AfriNIC.) # - /etc/hosts takes on the simple - format of: + The format of /etc/hosts is as + follows: [Internet address] [official hostname] [alias1] [alias2] ... For example: 10.0.0.1 myRealHostname.example.com myRealHostname foobar1 foobar2 Consult &man.hosts.5; for more information. - - - <filename>sysctl.conf</filename> - - sysctl.conf - sysctl - - sysctl.conf looks much like - rc.conf. Values are set in a - variable=value form. The specified values - are set after the system goes into multi-user mode. Not all - variables are settable in this mode. - - To turn off logging of fatal signal exits and prevent - users from seeing processes started from other users, the - following tunables can be set in - sysctl.conf: - - # Do not log fatal signal exits (e.g., sig 11) -kern.logsigexit=0 - -# Prevent users from seeing information about processes that -# are being run under another UID. -security.bsd.see_other_uids=0 - - Tuning with &man.sysctl.8; sysctl tuning with sysctl &man.sysctl.8; is used to make changes to a running &os; - system. This includes many advanced options of the TCP/IP stack - and virtual memory system that can dramatically improve - performance for an experienced system administrator. Over five - hundred system variables can be read and set using - &man.sysctl.8;. + system. This includes many advanced options of the + TCP/IP stack and virtual memory system + that can dramatically improve performance for an experienced + system administrator. Over five hundred system variables can + be read and set using &man.sysctl.8;. At its core, &man.sysctl.8; serves two functions: to read and to modify system settings. To view all readable variables: &prompt.user; sysctl -a - To read a particular variable, for example, - kern.maxproc: + To read a particular variable, specify its name: &prompt.user; sysctl kern.maxproc kern.maxproc: 1044 - To set a particular variable, use the intuitive + To set a particular variable, use the variable=value syntax: &prompt.root; sysctl kern.maxfiles=5000 kern.maxfiles: 2088 -> 5000 Settings of sysctl variables are usually either strings, - numbers, or booleans (a boolean being 1 for - yes or a 0 for no). + numbers, or booleans, where a a boolean is 1 + for yes or 0 for no. To automatically set some variables each time the machine boots, add them to /etc/sysctl.conf. For - more information refer to &man.sysctl.conf.5; and . + + <filename>sysctl.conf</filename> + + sysctl.conf + sysctl + + The configuration file for &man.sysctl.8;, + /etc/sysctl.conf, looks much like + /etc/rc.conf. Values are set in a + variable=value form. The specified values + are set after the system goes into multi-user mode. Not all + variables are settable in this mode. + + For example, to turn off logging of fatal signal exits + and prevent users from seeing processes started by other + users, the following tunables can be set in + /etc/sysctl.conf: + + # Do not log fatal signal exits (e.g., sig 11) +kern.logsigexit=0 + +# Prevent users from seeing information about processes that +# are being run under another UID. +security.bsd.see_other_uids=0 + + + Tom Rhodes Contributed by &man.sysctl.8; Read-only In some cases it may be desirable to modify read-only - &man.sysctl.8; values. While this is sometimes unavoidable, - it can only be done on (re)boot. + &man.sysctl.8; values, which will require a reboot of the + system. - For instance on some laptop models the &man.cardbus.4; - device will not probe memory ranges, and fail with errors - which look similar to: + For instance, on some laptop models the &man.cardbus.4; + device will not probe memory ranges and will fail with errors + similar to: cbb0: Could not map register memory device_probe_and_attach: cbb0 attach returned 12 - Cases like the one above usually require the modification - of some default &man.sysctl.8; settings which are set read - only. To overcome these situations a user can put - &man.sysctl.8; OIDs in their local - /boot/loader.conf. Default settings are - located in - /boot/defaults/loader.conf. - - Fixing the problem mentioned above would require a user to - set in - the aforementioned file. Now &man.cardbus.4; will work - properly. + The fix requires the modification of a read-only + &man.sysctl.8; setting. Add + to + /boot/loader.conf and reboot. Now + &man.cardbus.4; should work properly. Tuning Disks + The following section will discuss various tuning + mechanisms and options which may be applied to disk + devices. In many cases, disks with mechanical parts, + such as SCSI drives, will be the + bottleneck driving down the overall system performance. While + a solution is to install a drive without mechanical parts, + such as a solid state drive, mechanical drives are not + going away anytime in the near future. When tuning disks, + it is advisable to utilize the features of the &man.iostat.8; + command to test various changes to the system. This + command will allow the user to obtain valuable information + on system IO. + Sysctl Variables <varname>vfs.vmiodirenable</varname> vfs.vmiodirenable - The vfs.vmiodirenable sysctl variable - may be set to either 0 (off) or 1 (on); it is 1 by default. - This variable controls how directories are cached by the - system. Most directories are small, using just a single - fragment (typically 1 K) in the file system and less - (typically 512 bytes) in the buffer cache. With this - variable turned off (to 0), the buffer cache will only cache - a fixed number of directories even if the system has a huge - amount of memory. When turned on (to 1), this sysctl allows - the buffer cache to use the VM Page Cache to cache the - directories, making all the memory available for caching - directories. However, the minimum in-core memory used to - cache a directory is the physical page size (typically - 4 K) rather than 512  bytes. Keeping this option - enabled is recommended if the system is running any services - which manipulate large numbers of files. Such services can + The vfs.vmiodirenable &man.sysctl.8; + variable + may be set to either 0 (off) or + 1 (on). It is set to + 1 by default. This variable controls + how directories are cached by the system. Most directories + are small, using just a single fragment (typically 1 K) + in the file system and typically 512 bytes in the + buffer cache. With this variable turned off, the buffer + cache will only cache a fixed number of directories, even + if the system has a huge amount of memory. When turned on, + this &man.sysctl.8; allows the buffer cache to use the + VM page cache to cache the directories, + making all the memory available for caching directories. + However, the minimum in-core memory used to cache a + directory is the physical page size (typically 4 K) + rather than 512  bytes. Keeping this option enabled + is recommended if the system is running any services which + manipulate large numbers of files. Such services can include web caches, large mail systems, and news systems. - Keeping this option on will generally not reduce performance - even with the wasted memory but you should experiment to - find out. + Keeping this option on will generally not reduce + performance, even with the wasted memory, but one should + experiment to find out. <varname>vfs.write_behind</varname> vfs.write_behind - The vfs.write_behind sysctl variable + The vfs.write_behind &man.sysctl.8; + variable defaults to 1 (on). This tells the file system to issue media writes as full clusters are collected, which typically occurs when writing large sequential files. - The idea is to avoid saturating the buffer cache with dirty - buffers when it would not benefit I/O performance. However, - this may stall processes and under certain circumstances - should be turned off. + This avoids saturating the buffer cache with dirty buffers + when it would not benefit I/O performance. However, this + may stall processes and under certain circumstances should + be turned off. <varname>vfs.hirunningspace</varname> vfs.hirunningspace - The vfs.hirunningspace sysctl + The vfs.hirunningspace &man.sysctl.8; variable determines how much outstanding write I/O may be queued to disk controllers system-wide at any given - instance. The default is usually sufficient but on machines - with lots of disks, try bumping it up to four or five - megabytes. Note that setting too - high a value (exceeding the buffer cache's write threshold) - can lead to extremely bad clustering performance. Do not - set this value arbitrarily high! Higher write values may - add latency to reads occurring at the same time. - - There are various other buffer-cache and VM page cache - related sysctls. Modifying these values is not recommended - as the VM system does an extremely good job of automatically - tuning itself. + instance. The default is usually sufficient, but on + machines with many disks, try bumping it up to four or five + megabytes. Setting too high a value + which exceeds the buffer cache's write threshold can lead + to bad clustering performance. Do not set this value + arbitrarily high as higher write values may add latency to + reads occurring at the same time. + + There are various other buffer cache and + VM page cache related &man.sysctl.8; + values. Modifying these values is not recommended as the + VM system does a good job of + automatically tuning itself. <varname>vm.swap_idle_enabled</varname> vm.swap_idle_enabled - The vm.swap_idle_enabled sysctl - variable is useful in large multi-user systems with lots of - users entering and leaving the system and lots of idle - processes. Such systems tend to generate a great deal of - continuous pressure on free memory reserves. Turning this - feature on and tweaking the swapout hysteresis (in idle - seconds) via vm.swap_idle_threshold1 and + The vm.swap_idle_enabled + &man.sysctl.8; variable is useful in large multi-user + systems with many active login users and lots of idle + processes. Such systems tend to generate continuous + pressure on free memory reserves. Turning this feature on + and tweaking the swapout hysteresis (in idle seconds) via + vm.swap_idle_threshold1 and vm.swap_idle_threshold2 depresses the priority of memory pages associated with idle processes more quickly then the normal pageout algorithm. This gives a helping hand to the pageout daemon. Only turn this option on if needed, because the tradeoff is essentially pre-page memory sooner rather than later which eats more swap and disk bandwidth. In a small system this option will have a determinable effect, but in a large system that is already - doing moderate paging this option allows the VM system to - stage whole processes into and out of memory easily. + doing moderate paging, this option allows the + VM system to stage whole processes into + and out of memory easily. <varname>hw.ata.wc</varname> hw.ata.wc - &os; 4.3 flirted with turning off IDE write - caching. This reduced write bandwidth to IDE disks but was - considered necessary due to serious data consistency issues - introduced by hard drive vendors. The problem is that IDE - drives lie about when a write completes. With IDE write - caching turned on, IDE hard drives not only write data to - disk out of order, but will sometimes delay writing some - blocks indefinitely when under heavy disk loads. A crash or + Turning off IDE write caching reduces + write bandwidth to IDE disks, but may + sometimes be necessary due to data consistency issues + introduced by hard drive vendors. The problem is that + some IDE drives lie about when a write + completes. With IDE write caching + turned on, IDE hard drives write data + to disk out of order and will sometimes delay writing some + blocks indefinitely when under heavy disk load. A crash or power failure may cause serious file system corruption. - &os;'s default was changed to be safe. Unfortunately, the - result was such a huge performance loss that we changed - write caching back to on by default after the release. Check the default on the system by observing the - hw.ata.wc sysctl variable. If IDE write - caching is turned off, setting this variable back to 1 will - turn it back on. This must be done from the boot loader at - boot time as attempting to do it after the kernel boots - will have no effect. + hw.ata.wc &man.sysctl.8; variable. If + IDE write caching is turned off, one can + set this read-only variable to + 1 in + /boot/loader.conf in order to enable + it at boot time. For more information, refer to &man.ata.4;. <literal>SCSI_DELAY</literal> (<varname>kern.cam.scsi_delay</varname>) kern.cam.scsi_delay kernel options - SCSI_DELAY + SCSI DELAY - The SCSI_DELAY kernel config may be - used to reduce system boot times. The defaults are fairly - high and can be responsible for 15 - seconds of delay in the boot process. Reducing it to - 5 seconds usually works (especially with - modern drives). The kern.cam.scsi_delay - boot time tunable should be used. The tunable, and kernel - config option accept values in terms of + The SCSI_DELAY kernel configuration + option may be used to reduce system boot times. The + defaults are fairly high and can be responsible for + 15 seconds of delay in the boot process. + Reducing it to 5 seconds usually works + with modern drives. The + kern.cam.scsi_delay boot time tunable + should be used. The tunable and kernel configuration + option accept values in terms of milliseconds and not seconds. Soft Updates Soft Updates - tunefs + &man.tunefs.8; - The &man.tunefs.8; program can be used to fine-tune a - file system. This program has many different options, but for - now we are only concerned with toggling Soft Updates on and - off, which is done by: + To fine-tune a file system, use &man.tunefs.8;. This + program has many different options. To toggle Soft Updates + on and off, use: &prompt.root; tunefs -n enable /filesystem &prompt.root; tunefs -n disable /filesystem - A filesystem cannot be modified with &man.tunefs.8; while + A file system cannot be modified with &man.tunefs.8; while it is mounted. A good time to enable Soft Updates is before any partitions have been mounted, in single-user mode. - Soft Updates drastically improves meta-data performance, + Soft Updates is recommended for UFS + file systems as it drastically improves meta-data performance, mainly file creation and deletion, through the use of a memory - cache. We recommend to use Soft Updates on all of your file - systems. There are two downsides to Soft Updates that you - should be aware of: First, Soft Updates guarantees filesystem - consistency in the case of a crash but could very easily be - several seconds (even a minute!) behind updating the physical - disk. If your system crashes you may lose more work than - otherwise. Secondly, Soft Updates delays the freeing of - filesystem blocks. If you have a filesystem (such as the root - filesystem) which is almost full, performing a major update, + cache. There are two downsides to Soft Updates to be aware + of. First, Soft Updates guarantee file system consistency + in the case of a crash, but could easily be several seconds + or even a minute behind updating the physical disk. If the + system crashes, unwritten data may be lost. Secondly, Soft + Updates delay the freeing of file system blocks. If the + root file system is almost full, performing a major update, such as make installworld, can cause the - filesystem to run out of space and the update to fail. + file system to run out of space and the update to fail. More Details About Soft Updates Soft Updates details - There are two traditional approaches to writing a file - systems meta-data back to disk. (Meta-data updates are - updates to non-content data like inodes or - directories.) + Meta-data updates are updates to non-content data like + inodes or directories. There are two traditional approaches + to writing a file system's meta-data back to disk. Historically, the default behavior was to write out - meta-data updates synchronously. If a directory had been - changed, the system waited until the change was actually - written to disk. The file data buffers (file contents) were - passed through the buffer cache and backed up to disk later - on asynchronously. The advantage of this implementation is + meta-data updates synchronously. If a directory changed, + the system waited until the change was actually written to + disk. The file data buffers (file contents) were passed + through the buffer cache and backed up to disk later on + asynchronously. The advantage of this implementation is that it operates safely. If there is a failure during an - update, the meta-data are always in a consistent state. A + update, meta-data is always in a consistent state. A file is either created completely or not at all. If the data blocks of a file did not find their way out of the buffer cache onto the disk by the time of the crash, - &man.fsck.8; is able to recognize this and repair the - filesystem by setting the file length to 0. Additionally, - the implementation is clear and simple. The disadvantage is - that meta-data changes are slow. An - rm -r, for instance, touches all the - files in a directory sequentially, but each directory change - (deletion of a file) will be written synchronously to the - disk. This includes updates to the directory itself, to the - inode table, and possibly to indirect blocks allocated by - the file. Similar considerations apply for unrolling large - hierarchies (tar -x). - - The second case is asynchronous meta-data updates. This - is the default for Linux/ext2fs and - mount -o async for *BSD ufs. All - meta-data updates are simply being passed through the buffer - cache too, that is, they will be intermixed with the updates - of the file content data. The advantage of this + &man.fsck.8; recognizes this and repairs the file system + by setting the file length to + 0. Additionally, the implementation is + clear and simple. The disadvantage is that meta-data + changes are slow. For example, rm -r + touches all the files in a directory sequentially, but each + directory change will be written synchronously to the + disk. This includes updates to the directory itself, to + the inode table, and possibly to indirect blocks allocated + by the file. Similar considerations apply for unrolling + large hierarchies using tar -x. + + The second approach is to use asynchronous meta-data + updates. This is the default for a UFS + file system mounted with mount -o async. + Since all meta-data updates are also passed through the + buffer cache, they will be intermixed with the updates of + the file content data. The advantage of this implementation is there is no need to wait until each meta-data update has been written to disk, so all operations which cause huge amounts of meta-data updates work much - faster than in the synchronous case. Also, the - implementation is still clear and simple, so there is a low - risk for bugs creeping into the code. The disadvantage is - that there is no guarantee at all for a consistent state of - the filesystem. If there is a failure during an operation - that updated large amounts of meta-data (like a power - failure, or someone pressing the reset button), the - filesystem will be left in an unpredictable state. There is - no opportunity to examine the state of the filesystem when - the system comes up again; the data blocks of a file could - already have been written to the disk while the updates of - the inode table or the associated directory were not. It is - actually impossible to implement a fsck - which is able to clean up the resulting chaos (because the - necessary information is not available on the disk). If the - filesystem has been damaged beyond repair, the only choice - is to use &man.newfs.8; on it and restore it from - backup. - - The usual solution for this problem was to implement + faster than in the synchronous case. This implementation + is still clear and simple, so there is a low risk for bugs + creeping into the code. The disadvantage is that there is + no guarantee for a consistent state of the file system. + If there is a failure during an operation that updated + large amounts of meta-data, like a power failure or someone + pressing the reset button, the file system will be left + in an unpredictable state. There is no opportunity to + examine the state of the file system when the system comes + up again as the data blocks of a file could already have + been written to the disk while the updates of the inode + table or the associated directory were not. It is + impossible to implement a &man.fsck.8; which is able to + clean up the resulting chaos because the necessary + information is not available on the disk. If the file + system has been damaged beyond repair, the only choice + is to reformat it and restore from backup. + + The usual solution for this problem is to implement dirty region logging, which is also - referred to as journaling, although - that term is not used consistently and is occasionally - applied to other forms of transaction logging as well. + referred to as journaling. Meta-data updates are still written synchronously, but only - into a small region of the disk. Later on they will be - moved to their proper location. Because the logging area is - a small, contiguous region on the disk, there are no long + into a small region of the disk. Later on, they are moved + to their proper location. Because the logging area is a + small, contiguous region on the disk, there are no long distances for the disk heads to move, even during heavy operations, so these operations are quicker than synchronous - updates. Additionally the complexity of the implementation - is fairly limited, so the risk of bugs being present is low. - A disadvantage is that all meta-data are written twice (once - into the logging region and once to the proper location) so - for normal work, a performance pessimization - might result. On the other hand, in case of a crash, all - pending meta-data operations can be quickly either - rolled-back or completed from the logging area after the - system comes up again, resulting in a fast filesystem - startup. - - Kirk McKusick, the developer of Berkeley FFS, solved - this problem with Soft Updates: all pending meta-data - updates are kept in memory and written out to disk in a - sorted sequence (ordered meta-data updates). - This has the effect that, in case of heavy meta-data - operations, later updates to an item catch - the earlier ones if the earlier ones are still in memory and - have not already been written to disk. So all operations - on, say, a directory are generally performed in memory - before the update is written to disk (the data blocks are + updates. Additionally, the complexity of the implementation + is limited, so the risk of bugs being present is low. A + disadvantage is that all meta-data is written twice, once + into the logging region and once to the proper location, so + performance pessimization might result. On + the other hand, in case of a crash, all pending meta-data + operations can be either quickly rolled back or completed + from the logging area after the system comes up again, + resulting in a fast file system startup. + + Kirk McKusick, the developer of Berkeley + FFS, solved this problem with Soft + Updates. All pending meta-data updates are kept in memory + and written out to disk in a sorted sequence + (ordered meta-data updates). This has the + effect that, in case of heavy meta-data operations, later + updates to an item catch the earlier ones + which are still in memory and have not already been written + to disk. All operations are generally performed in memory + before the update is written to disk and the data blocks are sorted according to their position so that they will not be - on the disk ahead of their meta-data). If the system - crashes, this causes an implicit log rewind: - all operations which did not find their way to the disk - appear as if they had never happened. A consistent - filesystem state is maintained that appears to be the one of - 30 to 60 seconds earlier. The algorithm used guarantees - that all resources in use are marked as such in their - appropriate bitmaps: blocks and inodes. After a crash, the - only resource allocation error that occurs is that resources - are marked as used which are actually - free. &man.fsck.8; recognizes this situation, - and frees the resources that are no longer used. It is safe - to ignore the dirty state of the filesystem after a crash by - forcibly mounting it with mount -f. In - order to free resources that may be unused, &man.fsck.8; - needs to be run at a later time. This is the idea behind - the background fsck: at system startup - time, only a snapshot of the filesystem - is recorded. The fsck can be run later - on. All file systems can then be mounted + on the disk ahead of their meta-data. If the system + crashes, an implicit log rewind causes all + operations which were not written to the disk appear as if + they never happened. A consistent file system state is + maintained that appears to be the one of 30 to 60 seconds + earlier. The algorithm used guarantees that all resources + in use are marked as such in their blocks and inodes. + After a crash, the only resource allocation error that + occurs is that resources are marked as used + which are actually free. &man.fsck.8; + recognizes this situation, and frees the resources that + are no longer used. It is safe to ignore the dirty state + of the file system after a crash by forcibly mounting it + with mount -f. In order to free + resources that may be unused, &man.fsck.8; needs to be run + at a later time. This is the idea behind the + background &man.fsck.8;: at system + startup time, only a snapshot of the + file system is recorded and &man.fsck.8; is run afterwards. + All file systems can then be mounted dirty, so the system startup proceeds in - multiuser mode. Then, background fscks - will be scheduled for all file systems where this is - required, to free resources that may be unused. (File - systems that do not use Soft Updates still need the usual - foreground fsck though.) + multi-user mode. Then, background &man.fsck.8; is + scheduled for all file systems where this is required, to + free resources that may be unused. File systems that do + not use Soft Updates still need the usual foreground + &man.fsck.8;. The advantage is that meta-data operations are nearly - as fast as asynchronous updates which are, faster than + as fast as asynchronous updates and are faster than logging, which has to write the meta-data twice. The disadvantages are the complexity of - the code (implying a higher risk for bugs in an area that is - highly sensitive regarding loss of user data), and a higher - memory consumption. Additionally there are some - idiosyncrasies one has to get used to. After a crash, the - state of the filesystem appears to be somewhat - older. In situations where the standard - synchronous approach would have caused some zero-length - files to remain after the fsck, these - files do not exist at all with a Soft Updates filesystem - because neither the meta-data nor the file contents have - ever been written to disk. Disk space is not released until + the code, a higher memory consumption, and some + idiosyncrasies. After a crash, the state of the file + system appears to be somewhat older. In + situations where the standard synchronous approach would + have caused some zero-length files to remain after the + &man.fsck.8;, these files do not exist at all with Soft + Updates because neither the meta-data nor the file contents + have been written to disk. Disk space is not released until the updates have been written to disk, which may take place - some time after running rm. This may - cause problems when installing large amounts of data on a - filesystem that does not have enough free space to hold all - the files twice. + some time after running &man.rm.1;. This may cause problems + when installing large amounts of data on a file system + that does not have enough free space to hold all the files + twice. Tuning Kernel Limits tuning kernel limits File/Process Limits <varname>kern.maxfiles</varname> kern.maxfiles - kern.maxfiles can be raised or - lowered based upon system requirements. This variable - indicates the maximum number of file descriptors on the - system. When the file descriptor table is full, - file: table is full will show up - repeatedly in the system message buffer, which can be viewed - using dmesg. + The kern.maxfiles &man.sysctl.8; + variable can be raised or lowered based upon system + requirements. This variable indicates the maximum number + of file descriptors on the system. When the file descriptor + table is full, file: table is full + will show up repeatedly in the system message buffer, which + can be viewed using &man.dmesg.8;. Each open file, socket, or fifo uses one file descriptor. A large-scale production server may easily require many thousands of file descriptors, depending on the kind and number of services running concurrently. In older &os; releases, the default value of kern.maxfiles is derived from in the kernel configuration file. kern.maxfiles grows proportionally to the value of . When compiling a custom kernel, consider setting this kernel configuration option according to the use of the system. From this number, the kernel is given most of its pre-defined limits. Even though a production machine may not have 256 concurrent users, the resources needed may be similar to a high-scale web server. - The variable kern.maxusers is - automatically sized at boot based on the amount of memory - available in the system, and may be determined at run-time - by inspecting the value of the read-only - kern.maxusers sysctl. Some sites will - require larger or smaller values of - kern.maxusers and may set it as a loader - tunable; values of 64, 128, and 256 are not uncommon. Going - above 256 is not recommended unless a huge number of file - descriptors are needed. Many of the tunable values set to - their defaults by kern.maxusers may be - individually overridden at boot-time or run-time in + The read-only &man.sysctl.8; variable + kern.maxusers is automatically sized at + boot based on the amount of memory available in the system, + and may be determined at run-time by inspecting the value + of kern.maxusers. Some systems require + larger or smaller values of + kern.maxusers and values of + 64, 128, and + 256 are not uncommon. Going above + 256 is not recommended unless a huge + number of file descriptors is needed. Many of the tunable + values set to their defaults by + kern.maxusers may be individually + overridden at boot-time or run-time in /boot/loader.conf. Refer to &man.loader.conf.5; and /boot/defaults/loader.conf for more details and some hints. In older releases, the system will auto-tune maxusers if it is set to - 0 + 0. The auto-tuning algorithm sets maxusers equal to the amount of - memory in the system, with a minimum of 32, and a - maximum of 384.. When setting this - option, set maxusers to at least 4, - especially if the system runs - Xorg or is used to + memory in the system, with a minimum of + 32, and a maximum of + 384.. When + setting this option, set maxusers to + at least 4, especially if the system + runs &xorg; or is used to compile software. The most important table set by maxusers is the maximum number of processes, which is set to 20 + 16 * maxusers. If - maxusers is set to 1, there can only be - 36 simultaneous processes, including the 18 or so that the - system starts up at boot time and the 15 or so used by - Xorg. Even a simple task like + maxusers is set to 1, + there can only be + 36 simultaneous processes, including + the 18 or so that the system starts up + at boot time and the 15 or so used by + &xorg;. Even a simple task like reading a manual page will start up nine processes to filter, decompress, and view it. Setting - maxusers to 64 allows up to 1044 - simultaneous processes, which should be enough for nearly - all uses. If, however, you see the dreaded - proc table full error when trying to - start another program, or are running a server with a large - number of simultaneous users (like - ftp.FreeBSD.org), increase the - number and rebuild. + maxusers to 64 allows + up to 1044 simultaneous processes, which + should be enough for nearly all uses. If, however, the + proc table full error is displayed + when trying to start another program, or a server is + running with a large number of simultaneous users, increase + the number and rebuild. maxusers does not limit the number of users which - can log into your machine. It simply sets various table + can log into the machine. It instead sets various table sizes to reasonable values considering the maximum number of users on the system and how many processes each user will be running. <varname>kern.ipc.somaxconn</varname> kern.ipc.somaxconn - The kern.ipc.somaxconn sysctl + The kern.ipc.somaxconn &man.sysctl.8; variable limits the size of the listen queue for accepting - new TCP connections. The default value of - 128 is typically too low for robust - handling of new connections in a heavily loaded web server - environment. For such environments, it is recommended to - increase this value to 1024 or higher. - The service daemon may itself limit the listen queue size - (e.g., &man.sendmail.8;, or - Apache) but will often have a - directive in its configuration file to adjust the queue - size. Large listen queues also do a better job of avoiding - Denial of Service (DoS) attacks. + new TCP connections. The default value + of 128 is typically too low for robust + handling of new connections on a heavily loaded web server. + For such environments, it is recommended to increase this + value to 1024 or higher. A service + such as &man.sendmail.8;, or + Apache may itself limit the + listen queue size, but will often have a directive in its + configuration file to adjust the queue size. Large listen + queues do a better job of avoiding Denial of Service + (DoS) attacks. Network Limits The NMBCLUSTERS kernel configuration option dictates the amount of network Mbufs available to the system. A heavily-trafficked server with a low number of - Mbufs will hinder &os;'s ability. Each cluster represents - approximately 2 K of memory, so a value of 1024 - represents 2 megabytes of kernel memory reserved for network - buffers. A simple calculation can be done to figure out how - many are needed. A web server which maxes out at 1000 - simultaneous connections where each connection uses a - 6 K receive and 16 K send buffer, requires - approximately 32 MB worth of network buffers to cover the - web server. A good rule of thumb is to multiply by 2, so + Mbufs will hinder performance. Each cluster represents + approximately 2 K of memory, so a value of + 1024 represents 2 + megabytes of kernel memory reserved for network buffers. A + simple calculation can be done to figure out how many are + needed. A web server which maxes out at + 1000 simultaneous connections where each + connection uses a 6 K receive and 16 K send buffer, + requires approximately 32 MB worth of network buffers + to cover the web server. A good rule of thumb is to multiply + by 2, so 2x32 MB / 2 KB = - 64 MB / 2 kB = 32768. Values between - 4096 and 32768 are recommended for machines with greater - amounts of memory. Under no circumstances should you specify - an arbitrarily high value for this parameter as it could lead - to a boot time crash. To observe network cluster usage, use - with &man.netstat.1;. + 64 MB / 2 kB = + 32768. Values between + 4096 and 32768 are + recommended for machines with greater amounts of memory. + Never specify an arbitrarily high value for this parameter + as it could lead to a boot time crash. To observe network + cluster usage, use with + &man.netstat.1;. The kern.ipc.nmbclusters loader tunable should be used to tune this at boot time. Only older versions of &os; will require the use of the NMBCLUSTERS kernel &man.config.8; option. For busy servers that make extensive use of the &man.sendfile.2; system call, it may be necessary to increase the number of &man.sendfile.2; buffers via the NSFBUFS kernel configuration option or by setting its value in /boot/loader.conf (see &man.loader.8; for details). A common indicator that this parameter needs to be adjusted is when processes are seen - in the sfbufa state. The sysctl variable - kern.ipc.nsfbufs is a read-only glimpse at - the kernel configured variable. This parameter nominally - scales with kern.maxusers, however it may - be necessary to tune accordingly. + in the sfbufa state. The &man.sysctl.8; + variable kern.ipc.nsfbufs is read-only. + This parameter nominally scales with + kern.maxusers, however it may be necessary + to tune accordingly. Even though a socket has been marked as non-blocking, calling &man.sendfile.2; on the non-blocking socket may result in the &man.sendfile.2; call blocking until enough struct sf_buf's are made available. <varname>net.inet.ip.portrange.*</varname> net.inet.ip.portrange.* - The net.inet.ip.portrange.* sysctl + The net.inet.ip.portrange.* + &man.sysctl.8; variables control the port number ranges automatically bound - to TCP and UDP sockets. There are three ranges: a low - range, a default range, and a high range. Most network - programs use the default range which is controlled by the + to TCP and UDP + sockets. There are three ranges: a low range, a default + range, and a high range. Most network programs use the + default range which is controlled by net.inet.ip.portrange.first and net.inet.ip.portrange.last, which default - to 1024 and 5000, respectively. Bound port ranges are used - for outgoing connections, and it is possible to run the - system out of ports under certain circumstances. This most - commonly occurs when running a heavily loaded web proxy. - The port range is not an issue when running servers which - handle mainly incoming connections, such as a normal web - server, or has a limited number of outgoing connections, - such as a mail relay. For situations where there is a - shortage of ports, it is recommended to increase + to 1024 and 5000, + respectively. Bound port ranges are used for outgoing + connections and it is possible to run the system out of + ports under certain circumstances. This most commonly + occurs when running a heavily loaded web proxy. The port + range is not an issue when running a server which handles + mainly incoming connections, such as a web server, or has + a limited number of outgoing connections, such as a mail + relay. For situations where there is a shortage of ports, + it is recommended to increase net.inet.ip.portrange.last modestly. A value of 10000, 20000 or 30000 may be reasonable. Consider firewall effects when changing the port range. Some - firewalls may block large ranges of ports (usually - low-numbered ports) and expect systems to use higher ranges - of ports for outgoing connections — for this reason it - is not recommended that + firewalls may block large ranges of ports, usually + low-numbered ports, and expect systems to use higher ranges + of ports for outgoing connections. For this reason, it + is not recommended that the value of net.inet.ip.portrange.first be lowered. - TCP Bandwidth Delay Product + <literal>TCP</literal> Bandwidth Delay Product - TCP Bandwidth Delay Product Limiting + TCP Bandwidth Delay Product + Limiting net.inet.tcp.inflight.enable - The TCP Bandwidth Delay Product Limiting is similar to - TCP/Vegas in NetBSD. It can be enabled by setting - net.inet.tcp.inflight.enable sysctl - variable to 1. The system will attempt - to calculate the bandwidth delay product for each connection - and limit the amount of data queued to the network to just - the amount required to maintain optimum throughput. + TCP bandwidth delay product limiting + can be enabled by setting the + net.inet.tcp.inflight.enable + &man.sysctl.8; variable to 1. This + instructs the system to attempt to calculate the bandwidth + delay product for each connection and limit the amount of + data queued to the network to just the amount required to + maintain optimum throughput. This feature is useful when serving data over modems, - Gigabit Ethernet, or even high speed WAN links (or any other - link with a high bandwidth delay product), especially when - also using window scaling or when a large send window has - been configured. When enabling this option, also be sure to - set net.inet.tcp.inflight.debug to - 0 (disable debugging), and for production - use setting net.inet.tcp.inflight.min to - at least 6144 may be beneficial. - However, note that setting high minimums may effectively - disable bandwidth limiting depending on the link. The - limiting feature reduces the amount of data built up in - intermediate route and switch packet queues and reduces the - amount of data built up in the local host's interface queue. - With fewer queued packets, interactive connections, - especially over slow modems, will operate with lower + Gigabit Ethernet, high speed WAN links, + or any other link with a high bandwidth delay product, + especially when also using window scaling or when a large + send window has been configured. When enabling this option, + also set net.inet.tcp.inflight.debug to + 0 to disable debugging. For production + use, setting net.inet.tcp.inflight.min + to at least 6144 may be beneficial. + Setting high minimums may effectively disable bandwidth + limiting, depending on the link. The limiting feature + reduces the amount of data built up in intermediate route + and switch packet queues and reduces the amount of data + built up in the local host's interface queue. With fewer + queued packets, interactive connections, especially over + slow modems, will operate with lower Round Trip Times. This feature only - effects server side data transmission such as uploading. It - has no effect on data reception or downloading. + effects server side data transmission such as uploading. + It has no effect on data reception or downloading. Adjusting net.inet.tcp.inflight.stab is not recommended. This parameter - defaults to 20, representing 2 maximal packets added to the - bandwidth delay product window calculation. The additional - window is required to stabilize the algorithm and improve - responsiveness to changing conditions, but it can also - result in higher ping times over slow links, though still - much lower than without the inflight algorithm. In such - cases, try reducing this parameter to 15, 10, or 5; and - reducing net.inet.tcp.inflight.min (for - example, to 3500) to get the desired effect. Reducing these - parameters should be done as a last resort only. + defaults to 20, representing 2 maximal + packets added to the bandwidth delay product window + calculation. The additional window is required to stabilize + the algorithm and improve responsiveness to changing + conditions, but it can also result in higher &man.ping.8; + times over slow links, though still much lower than without + the inflight algorithm. In such cases, try reducing this + parameter to 15, + 10, or 5 and + reducing net.inet.tcp.inflight.min + to a value such as 3500 to get the + desired effect. Reducing these parameters should be done + as a last resort only. Virtual Memory <varname>kern.maxvnodes</varname> A vnode is the internal representation of a file or - directory. So increasing the number of vnodes available to - the operating system cuts down on disk I/O. Normally this - is handled by the operating system and does not need to be + directory. Increasing the number of vnodes available to + the operating system reduces disk I/O. Normally, this is + handled by the operating system and does not need to be changed. In some cases where disk I/O is a bottleneck and - the system is running out of vnodes, this setting will need - to be increased. The amount of inactive and free RAM will - need to be taken into account. + the system is running out of vnodes, this setting needs + to be increased. The amount of inactive and free + RAM will need to be taken into + account. To see the current number of vnodes in use: &prompt.root; sysctl vfs.numvnodes vfs.numvnodes: 91349 To see the maximum vnodes: &prompt.root; sysctl kern.maxvnodes kern.maxvnodes: 100000 - If the current vnode usage is near the maximum, + If the current vnode usage is near the maximum, try increasing kern.maxvnodes by a value of - 1,000 is probably a good idea. Keep an eye on the number of + 1000. Keep an eye on the number of vfs.numvnodes. If it climbs up to the maximum again, kern.maxvnodes will need - to be increased further. A shift in your memory usage as - reported by &man.top.1; should be visible. More memory - should be active. + to be increased further. Otherwise, a shift in memory + usage as reported by &man.top.1; should be visible and + more memory should be active. Adding Swap Space - Despite careful planning, sometimes a system does not run - as expected. If more swap space is needed, it is simple enough - to add. There are three ways to increase swap space: add a new - hard drive, enable swap over NFS, or create a swap file on an - existing partition. + Sometimes a system requires more swap space. There are + three ways to increase swap space: add a new hard drive, + enable swap over NFS, or create a swap file + on an existing partition. - For information on how to encrypt swap space, what options - for this task exist and why it should be done, refer to - of the Handbook. + For information on how to encrypt swap space, which options + exist, and why it should be done, refer to . Swap on a New or Existing Hard Drive Adding a new hard drive for swap gives better performance than adding a partition on an existing drive. Setting up - partitions and hard drives is explained in - . - discusses partition + partitions and hard drives is explained in while discusses partition layouts and swap partition size considerations. Use &man.swapon.8; to add a swap partition to the system. For example: &prompt.root; swapon /dev/ada1s1b It is possible to use any partition not currently mounted, even if it already contains data. Using &man.swapon.8; on a partition that contains data will overwrite and destroy that data. Make sure that the partition to be added as swap is really the intended partition before running &man.swapon.8;. To automatically add this swap partition on boot, add an - entry to /etc/fstab for the - partition: + entry to /etc/fstab: /dev/ada1s1b none swap sw 0 0 See &man.fstab.5; for an explanation of the entries in /etc/fstab. - Swapping over NFS + Swapping over <literal>NFS</literal> - Swapping over NFS is only recommended if you do not have a - local hard disk to swap to; NFS swapping will be limited by - the available network bandwidth and puts an additional burden - on the NFS server. + Swapping over NFS is only recommended + when there is no local hard disk to swap to. + NFS swapping will be limited by the + available network bandwidth and puts an additional burden + on &man.nfsd.8;. Swapfiles - You can create a file of a specified size to use as a swap - file. The following example will create a 64MB file named + To create a swap file, specify its size. The following + example creates a 64MB file named /usr/swap0. Creating a Swapfile on &os; The GENERIC kernel already includes the memory disk driver (&man.md.4;) required - for this operation. When building a custom kernel, make - sure to include the following line in the custom + for this operation. When building a custom kernel, + make sure to include the following line in the custom configuration file: device md For information on building a custom kernel, refer to . - Create a swapfile - (/usr/swap0): + First, create the swapfile + /usr/swap0: &prompt.root; dd if=/dev/zero of=/usr/swap0 bs=1024k count=64 - Set proper permissions on - (/usr/swap0): + Then, set proper permissions on + /usr/swap0: &prompt.root; chmod 0600 /usr/swap0 Enable the swap file in /etc/rc.conf: swapfile="/usr/swap0" # Set to name of swapfile if aux swapfile desired. - Reboot the machine or to enable the swap file + Reboot the machine or, to enable the swap file immediately, type: &prompt.root; mdconfig -a -t vnode -f /usr/swap0 -u 0 && swapon /dev/md0 Hiten Pandya Written by Tom Rhodes Power and Resource Management It is important to utilize hardware resources in an efficient manner. Before the Advanced Configuration and Power Interface (ACPI) was introduced, it was difficult and inflexible for operating systems to manage the power usage and thermal properties of a system. The hardware was managed by the BIOS and the user had less control and visibility into the power management settings. Some limited configurability was available via Advanced - Power Management (APM). Power and resource - management is one of the key components of a modern operating - system. It allows the operating system to monitor system - limits and to possibly provide an alert if the system + Power Management (APM). Power + and resource management allows the operating system to monitor + system limits and to possibly provide an alert if the system temperature increases unexpectedly. This section provides comprehensive information about ACPI. References will be provided for further reading. What Is ACPI? ACPI APM ACPI is a standard written by an alliance of vendors to provide a standard interface for hardware resources and power management. It is a key element in Operating System-directed configuration and Power Management as it provides more control and flexibility to the operating system. Modern systems stretched the limits of the current Plug and Play interfaces prior to the introduction of ACPI. ACPI is the direct successor to APM. - Shortcomings of Advanced Power Management (APM) + Shortcomings of Advanced Power Management The APM facility controls the power - usage of a system based on its activity. The APM BIOS is - supplied by the (system) vendor and is specific to the - hardware platform. An APM driver in the operating system - mediates access to the APM Software - Interface, which allows management of power - levels. APM should still be used for systems manufactured at - or before the year 2000. - - There are four major problems in APM. Firstly, power - management is done by the (vendor-specific) BIOS, and the OS - does not have any knowledge of it. One example of this, is - when the user sets idle-time values for a hard drive in the - APM BIOS, that when exceeded, it (BIOS) would spin down the - hard drive, without the consent of the OS. Secondly, the APM - logic is embedded in the BIOS, and it operates outside the - scope of the OS. This means users can only fix problems in - their APM BIOS by flashing a new one into the ROM; which is a - very dangerous procedure with the potential to leave the - system in an unrecoverable state if it fails. Thirdly, APM is - a vendor-specific technology, which means that there is a lot - of parity (duplication of efforts) and bugs found in one - vendor's BIOS, may not be solved in others. Last but not the - least, the APM BIOS did not have enough room to implement a - sophisticated power policy, or one that can adapt very well to - the purpose of the machine. - - Plug and Play BIOS (PNPBIOS) was - unreliable in many situations. PNPBIOS is 16-bit technology, - so the OS has to use 16-bit emulation in order to - interface with PNPBIOS methods. + usage of a system based on its activity. The + APM BIOS is supplied + by the vendor and is specific to the hardware platform. An + APM driver in the operating system + mediates access to the APM + Software Interface, which allows management of + power levels. APM should still be used + for systems manufactured at or before the year 2000. + + There are four major problems in APM. + First, power management is done by the vendor-specific + BIOS, separate from the operating system. + For example, the user can set idle-time values for a hard + drive in the APM BIOS + so that, when exceeded, the BIOS spins + down the hard drive without the consent of the operating + system. Second, the APM logic is embedded + in the BIOS, and it operates outside the + scope of the operating system. This means that users can + only fix problems in the APM + BIOS by flashing a new one into the + ROM, which is a dangerous procedure with + the potential to leave the system in an unrecoverable state + if it fails. Third, APM is a + vendor-specific technology, meaning that there is a lot of + duplication of efforts and bugs found in one vendor's + BIOS may not be solved in others. Lastly, + the APM BIOS did not + have enough room to implement a sophisticated power policy + or one that can adapt well to the purpose of the + machine. + + The Plug and Play BIOS + (PNPBIOS) was unreliable in + many situations. PNPBIOS is 16-bit + technology, so the operating system has to use 16-bit + emulation in order to interface with + PNPBIOS methods. The &os; APM driver is documented in - the &man.apm.4; manual page. + &man.apm.4;. Configuring <acronym>ACPI</acronym> - The acpi.ko driver is loaded by - default at start up by the &man.loader.8; and should + The &man.acpi.4; driver is loaded by default at start + up by &man.loader.8; and should not be compiled into the kernel. The - reasoning behind this is that modules are easier to work with, - say if switching to another acpi.ko - without doing a kernel rebuild. This has the advantage of - making testing easier. Another reason is that starting + reasoning is that modules are easier to work with and do not + require a kernel rebuild. This has the advantage of making + testing easier. Another reason is that starting ACPI after a system has been brought up - often does not work well. If you are experiencing problems, + often does not work well. If experiencing problems, ACPI can be disabled altogether. This driver should not and can not be unloaded because the system bus uses it for various hardware interactions. - ACPI can be disabled by setting - hint.acpi.0.disabled="1" in - /boot/loader.conf or at the - &man.loader.8; prompt. + ACPI can be disabled by rebooting after + setting hint.acpi.0.disabled="1" in + /boot/loader.conf or by setting this + variable at the &man.loader.8; prompt. ACPI and APM cannot coexist and should be used separately. The last one - to load will terminate if the driver notices the other + to load will terminate if the driver notices the other is running. ACPI can be used to put the system into a sleep mode with &man.acpiconf.8;, the - flag, and a 1-5 option. Most users will - only need 1 or 3 - (suspend to RAM). Option 5 will do a - soft-off which is the same action as: + flag, and a 1-5 option. Most users + only need 1 (quick suspend to + RAM) or 3 (suspend to + RAM). Option 5 performs + a soft-off which is the same action as: &prompt.root; halt -p - Other options are available via &man.sysctl.8;. Check out - the &man.acpi.4; and &man.acpiconf.8; manual pages for more - information. + Other options are available via &man.sysctl.8;. Refer to + &man.acpi.4; and &man.acpiconf.8; for more information. Nate Lawson Written by Peter Schultz With contributions from Tom Rhodes Using and Debugging &os; <acronym>ACPI</acronym> ACPI problems ACPI is a fundamentally new way of discovering devices, managing power usage, and providing standardized access to various hardware previously managed by the BIOS. Progress is being made toward ACPI working on all systems, but bugs in some motherboards' ACPI Machine Language (AML) bytecode, incompleteness in &os;'s kernel subsystems, and bugs in the &intel; ACPI-CA interpreter continue to appear. This section is intended to help users assist the &os; ACPI maintainers in identifying the root - cause of problems you observe and debugging and developing a + cause of problems and in debugging and developing a solution. Submitting Debugging Information - Before submitting a problem, be sure you are running the - latest BIOS version and, if available, - embedded controller firmware version. + Before submitting a problem, ensure the latest + BIOS version is installed and, if + available, the embedded controller firmware version. When submitting a problem, send the following information to freebsd-acpi@FreeBSD.org: Description of the buggy behavior, including system type and model and anything that causes the bug to appear. Note as accurately as possible when the bug began occurring if it is new. - The &man.dmesg.8; output after + The output of &man.dmesg.8; after running boot -v, including any error messages generated by the bug. - The &man.dmesg.8; output from - boot -v with ACPI - disabled, if disabling it helps fix the problem. + The &man.dmesg.8; output from boot + -v with ACPI disabled, + if disabling it helps to fix the problem. Output from sysctl hw.acpi. This - is also a good way of figuring out what features the - system offers. + lists which features the system offers. - URL where the + The URL to a pasted version of the ACPI Source - Language (ASL) can be - found. Do not send the + Language (ASL). Do + not send the ASL directly to the list as it can be very large. Generate a copy of the ASL by running this command: &prompt.root; acpidump -dt > name-system.asl - (Substitute your login name for + Substitute the login name for name and manufacturer/model for - system. Example: - njl-FooCo6000.asl) + system. For example, use + njl-FooCo6000.asl. Most &os; developers watch &a.current;, but one should - submit problems to &a.acpi.name; to be sure it is - seen. Be patient when waiting for a response. If the bug is - not immediately apparent, you may be asked to submit a + submit problems to &a.acpi.name; to be sure it is seen. Be + patient when waiting for a response. If the bug is not + immediately apparent, submit a PR using &man.send-pr.1;. When entering a PR, include the same information as requested above. This helps developers to track the problem and resolve it. Do not send a PR without emailing &a.acpi.name; first as it is likely that the problem has been reported before. Background - ACPI + ACPI ACPI is present in all modern computers that conform to the ia32 (x86), ia64 (Itanium), and amd64 (AMD) architectures. The full standard has many features including CPU performance management, power planes control, thermal zones, various battery systems, embedded controllers, and bus enumeration. Most systems implement less than the full standard. For instance, a - desktop system usually only implements the bus enumeration - parts while a laptop might have cooling and battery management + desktop system usually only implements bus enumeration + while a laptop might have cooling and battery management support as well. Laptops also have suspend and resume, with their own associated complexity. An ACPI-compliant system has various components. The BIOS and chipset vendors - provide various fixed tables (e.g., FADT) + provide various fixed tables, such as FADT, in memory that specify things like the APIC map (used for SMP), config registers, and - simple configuration values. Additionally, a table of - bytecode (the Differentiated System Description - Table DSDT) is provided that - specifies a tree-like name space of devices and - methods. + simple configuration values. Additionally, a bytecode table, + the Differentiated System Description + Table DSDT, specifies a + tree-like name space of devices and methods. The ACPI driver must parse the fixed tables, implement an interpreter for the bytecode, and modify device drivers and the kernel to accept information from the ACPI subsystem. For &os;, &intel; has provided an interpreter (ACPI-CA) that is - shared with Linux and NetBSD. The path to the + shared with &linux; and NetBSD. The path to the ACPI-CA source code is src/sys/contrib/dev/acpica. The glue code that allows ACPI-CA to work - on &os; is in - src/sys/dev/acpica/Osd. + on &os; is in src/sys/dev/acpica/Osd. Finally, drivers that implement various ACPI devices are found in src/sys/dev/acpica. Common Problems ACPI problems For ACPI to work correctly, all the parts have to work correctly. Here are some common problems, in order of frequency of appearance, and some possible workarounds or fixes. Mouse Issues In some cases, resuming from a suspend operation will cause the mouse to fail. A known work around is to add hint.psm.0.flags="0x3000" to - /boot/loader.conf. If this does - not work, consider sending a bug report using + /boot/loader.conf. If this does not + work, consider sending a bug report using &man.send-pr.1;. Suspend/Resume ACPI has three suspend to RAM (STR) states, S1-S3, and one suspend to disk state (STD), called S4. S5 is soft off and is the normal state the system is in when plugged in but not powered up. - S4 can actually be implemented two - separate ways. S4BIOS - is a BIOS-assisted suspend to disk. + S4 can be implemented in two separate + ways. S4BIOS is a + BIOS-assisted suspend to disk. S4OS is implemented entirely by the operating system. Start by checking sysctl hw.acpi for the suspend-related items. Here are the results for a Thinkpad: hw.acpi.supported_sleep_state: S3 S4 S5 hw.acpi.s4bios: 0 Use acpiconf -s to test S3, S4OS, and S5. An of one (1), indicates S4BIOS support instead of S4 OS. When testing suspend/resume, start with S1, if supported. This state is most likely to work since it does not require much driver - support. No one has implemented S2 which - is similar to S1. The next thing to try - is S3. This is the deepest + support. No one has implemented S2, + which is similar to S1. Next, try + S3. This is the deepest STR state and requires a lot of driver - support to properly reinitialize the hardware. If you have - problems resuming, feel free to email &a.acpi.name;, but do - not expect the problem to be resolved since there are a lot + support to properly reinitialize the hardware. If there are + problems resuming, email &a.acpi.name;. However, the + problem may not be resolved quickly since due to the amount of drivers and hardware that need more testing and work. A common problem with suspend/resume is that many device drivers do not save, restore, or reinitialize their firmware, registers, or device memory properly. As a first attempt at debugging the problem, try: &prompt.root; sysctl debug.bootverbose=1 &prompt.root; sysctl debug.acpi.suspend_bounce=1 &prompt.root; acpiconf -s 3 - This test emulates suspend/resume cycle of all device - drivers without actually going into S3 - state. In some cases, problems such as losing firmware - state, device watchdog time out, and retrying forever, can - be captured with this method. Note that the system will - not really enter S3 state, which means - devices may not lose power, and many will work fine even if - suspend/resume methods are totally missing, unlike real - S3 state. + This test emulates the suspend/resume cycle of all + device drivers without actually going into + S3 state. In some cases, problems such + as losing firmware state, device watchdog time out, and + retrying forever, can be captured with this method. Note + that the system will not really enter S3 + state, which means devices may not lose power, and many + will work fine even if suspend/resume methods are totally + missing, unlike real S3 state. Harder cases require additional hardware, such as a - serial port/cable for serial console or a Firewire - port/cable for &man.dcons.4;, and kernel debugging - skills. + serial port and cable for debugging through a serial + console, a Firewire port and cable for using &man.dcons.4;, + and kernel debugging skills. - To help isolate the problem, remove as many drivers from - the kernel as possible. If it works, narrow down which + To help isolate the problem, remove as many drivers + from the kernel as possible. If it works, narrow down which driver is the problem by loading drivers until it fails - again. Typically binary drivers like + again. Typically, binary drivers like nvidia.ko, display drivers, and USB will have the most problems while - Ethernet interfaces usually work fine. If you can properly - load/unload the drivers, automate this by putting the + Ethernet interfaces usually work fine. If drivers can be + properly loaded and unloaded, automate this by putting the appropriate commands in /etc/rc.suspend and - /etc/rc.resume. There is a - commented-out example for unloading and loading a driver. - Try setting to zero - (0) if the display is messed up after + /etc/rc.resume. + Try setting to + 0 if the display is messed up after resume. Try setting longer or shorter values for to see if that helps. - Another thing to try is load a recent Linux distribution - with ACPI support and test their - suspend/resume support on the same hardware. If it works on - Linux, it is likely a &os; driver problem and narrowing down - which driver causes the problems will help us fix the - problem. Note that the ACPI maintainers - do not usually maintain other drivers, such as sound or - ATA, so any work done on tracking - down a driver problem should probably eventually be posted - to the &a.current.name; list and mailed to the driver - maintainer. Advanced users can start by putting some - debugging &man.printf.3;s in a problematic driver to track - down where in its resume function it hangs. + Try loading a recent &linux; distribution to see if + suspend/resume works on the same hardware. If it works on + &linux;, it is likely a &os; driver problem. Narrowing down + which driver causes the problem will assist developers in + fixing the problem. Since the ACPI + maintainers rarely maintain other drivers, such as sound + or ATA, any driver problems should also + be posted to the &a.current.name; list and mailed to the + driver maintainer. Advanced users can include debugging + &man.printf.3;s in a problematic driver to track down where + in its resume function it hangs. Finally, try disabling ACPI and enabling APM instead. If suspend/resume - works with APM, you may be better off - sticking with APM, especially on older - hardware (pre-2000). It took vendors a while to get + works with APM, stick with + APM, especially on older hardware + (pre-2000). It took vendors a while to get ACPI support correct and older hardware is more likely to have BIOS problems with ACPI. - System Hangs (Temporary or Permanent) + System Hangs Most system hangs are a result of lost interrupts or an - interrupt storm. Chipsets have a lot of problems based on + interrupt storm. Chipsets may have problems based on boot, how the BIOS configures interrupts before - boot, correctness of the APIC + correctness of the APIC (MADT) table, and routing of the System Control Interrupt (SCI). interrupt storms Interrupt storms can be distinguished from lost interrupts by checking the output of - vmstat -i and looking at the line that has acpi0. If the counter is increasing at more than a couple per second, there is an interrupt storm. If the system appears hung, try breaking to DDB ( CTRL ALT ESC on console) and type show interrupts. APIC disabling - When dealing with interrupt problems try disabling + When dealing with interrupt problems, try disabling APIC support with hint.apic.0.disabled="1" in - loader.conf. + /boot/loader.conf. Panics Panics are relatively rare for ACPI and are the top priority to be fixed. The first step is to - isolate the steps to reproduce the panic (if possible) and + isolate the steps to reproduce the panic, if possible, and get a backtrace. Follow the advice for enabling options DDB and setting up a serial - console (see ) or setting + console in or setting up a &man.dump.8; partition. To get a backtrace in DDB, use tr. When - handwriting the backtrace, get at least the lowest five (5) - and top five (5) lines in the trace. + handwriting the backtrace, get at least the last five + and the top five lines in the trace. Then, try to isolate the problem by booting with ACPI disabled. If that works, isolate the ACPI subsystem by using various values of . See &man.acpi.4; for some examples. System Powers Up After Suspend or Shutdown First, try setting - hw.acpi.disable_on_poweroff="0" - in &man.loader.conf.5;. This keeps ACPI + hw.acpi.disable_on_poweroff="0" in + &man.loader.conf.5;. This keeps ACPI from disabling various events during the shutdown process. Some systems need this value set to 1 (the default) for the same reason. This usually fixes the problem of a system powering up spontaneously after a suspend or poweroff. Other Problems - For other problems with ACPI such as + For other problems with ACPI, such as it not working with a docking station or devices not being - detected, email a description to the mailing list. Some + detected, email a description to &a.acpi.name;. Some issues may be related to unfinished parts of the ACPI subsystem which might take a while to be implemented. Be patient and prepared to test patches. - <acronym>ASL</acronym>, <command>acpidump</command>, and + <title><acronym>ASL</acronym>, &man.acpidump.8;, and <acronym>IASL</acronym> - ACPI - ASL + ACPI + ASL - The most common problem is the BIOS - vendors providing incorrect (or outright buggy!) bytecode. - This is usually manifested by kernel console messages like - this: + Some BIOS vendors provide incorrect + or buggy bytecode. This is usually manifested by kernel + console messages like this: ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.FIGD._STA] \\ (Node 0xc3f6d160), AE_NOT_FOUND Often, these problems may be resolved by updating the BIOS to the latest revision. Most console - messages are harmless but if when there are other problems - like the battery status is not working, these messages are a - good place to start looking for problems in the - AML. The bytecode, known as - AML, is compiled from a source language - called ASL. The AML is - found in the table known as the DSDT. To - get a copy of the system's ASL, use - &man.acpidump.8;. Include both , to - show the contents of the fixed tables, and - , to disassemble the - AML. Refer to Submitting Debugging - Information for an example syntax. + messages are harmless, but if there are other problems like + the battery status is not working, these messages are a + good place to start looking for problems. The bytecode, + known as AML, is compiled from a source + language called ASL. The + AML is found in the table known as the + DSDT. To get a copy of the system's + ASL, use &man.acpidump.8;. Include both + , to show the contents of the fixed tables, + and , to disassemble the + AML. Refer to for an example syntax. The simplest first check is to recompile the ASL to check for errors. Warnings can usually be ignored, but errors are bugs that will usually prevent ACPI from working correctly. To recompile the ASL, issue the following command: &prompt.root; iasl your.asl - Fixing Your <acronym>ASL</acronym> + Fixing the <acronym>ASL</acronym> - ACPI - ASL + ACPI + ASL - In the long run, the goal of &os; is for almost everyone - to have working ACPI without any user - intervention. At this point, workarounds are still being - developed for common mistakes made by the - BIOS vendors. The µsoft; interpreter - (acpi.sys and + The goal of &os; is for everyone to have working + ACPI without any user intervention. At + this point, workarounds are still being developed for common + mistakes made by BIOS vendors. The + µsoft; interpreter (acpi.sys and acpiec.sys) does not strictly check for adherence to the standard, and thus many BIOS vendors who only test ACPI under &windows; never fix their ASL. &os; developers continue to identify - and document exactly what non-standard behavior is allowed by - µsoft;'s interpreter and replicate it so &os; can work - without forcing users to fix the ASL. As a - workaround, and to help identify behavior, fix the + and document which non-standard behavior is allowed by + µsoft;'s interpreter and replicate it so that &os; can + work without forcing users to fix the ASL. + As a workaround, and to help identify behavior, fix the ASL manually. If this works, send a &man.diff.1; of the old and new ASL so developers can possibly work around the buggy behavior in - ACPI-CA and thus make the unnecessary - fix. + ACPI-CA. - ACPI + ACPI error messages Here is a list of common error messages, their cause, and how to fix them: - _OS Dependencies - - Some AML assumes the world consists - of various &windows; versions. You can tell &os; to claim - it is any OS to see if this fixes - problems you may have. An easy way to override this is to - set hw.acpi.osname="Windows 2001" in - /boot/loader.conf or other similar - strings you find in the ASL. + Operating System Dependencies + + Some AML versions assume the user is + running &windows;. To override this, set + hw.acpi.osname="Windows + 2001" in + /boot/loader.conf, using the strings + in the ASL. Missing Return Statements Some methods do not explicitly return a value as the standard requires. While ACPI-CA does not handle this, &os; has a workaround that allows it - to return the value implicitly. Explicit Return statements - can be added where required if you know what value should be - returned. To force iasl to compile the + to return the value implicitly. Explicit return statements + can be added where required if the value which should be + returned is known. To force &man.iasl.8; to compile the ASL, use the flag. Overriding the Default <acronym>AML</acronym> After customizing your.asl, compile it with this command: &prompt.root; iasl your.asl - Adding the flag will force creation + Adding the flag forces creation of the AML, even if there are errors - during compilation. Some errors, such as missing Return + during compilation. Some errors, such as missing return statements, are automatically worked around by the interpreter. - DSDT.aml is the default output - filename for iasl. Load this file - instead of the BIOS's buggy copy, which - is still present in flash memory, by editing - /boot/loader.conf as - follows: + The default output filename for &man.iasl.8; is + DSDT.aml. Load this file instead of + the BIOS's buggy copy, which is still + present in flash memory, by editing + /boot/loader.conf as follows: acpi_dsdt_load="YES" acpi_dsdt_name="/boot/DSDT.aml" Be sure to copy DSDT.aml to /boot. Getting Debugging Output from <acronym>ACPI</acronym> ACPI problems ACPI debugging - The ACPI driver has a very flexible + The ACPI driver has a flexible debugging facility. A set of subsystems and the level of verbosity can be specified. The subsystems to debug are specified as layers and are broken down into ACPI-CA components (ACPI_ALL_COMPONENTS) and ACPI hardware support (ACPI_ALL_DRIVERS). The verbosity of debugging output is specified as the level and ranges from ACPI_LV_ERROR (just report errors) to ACPI_LV_VERBOSE (everything). The level is a bitmask so multiple options can be set at once, separated by spaces. In - practice, a serial console should be used to log the output if - it is so long it flushes the console message buffer. A full - list of the individual layers and levels is found in + practice, a serial console should be used to log the output + so it is not lost as the console message buffer flushes. + A full list of the individual layers and levels is found in &man.acpi.4;. Debugging output is not enabled by default. To enable it, add options ACPI_DEBUG to the kernel configuration file if ACPI is compiled into the kernel. Add ACPI_DEBUG=1 to - /etc/make.conf to enable it - globally. If it is a module, recompile just the + /etc/make.conf to enable it globally. + If it is a module, recompile just the acpi.ko module as follows: &prompt.root; cd /sys/modules/acpi/acpi && make clean && make ACPI_DEBUG=1 - Install acpi.ko in - /boot/kernel and add - the desired level and layer to - loader.conf. This example enables debug - messages for all ACPI-CA components and all - ACPI hardware drivers such as + Install acpi.ko in /boot/kernel and add the + desired level and layer to + /boot/loader.conf. This example enables + debug messages for all ACPI-CA components + and all ACPI hardware drivers such as (CPU and LID. It only outputs error messages at the least verbose level. debug.acpi.layer="ACPI_ALL_COMPONENTS ACPI_ALL_DRIVERS" debug.acpi.level="ACPI_LV_ERROR" If the required information is triggered by a specific event, such as a suspend and then resume, leave out changes to - loader.conf and instead use - sysctl to specify the layer and level after - booting and preparing the system for the specific event. The - sysctls are named the same as the tunables - in loader.conf. + /boot/loader.conf and instead use + &man.sysctl.8; to specify the layer and level after booting + and preparing the system for the specific event. The + variables which can be set using &man.sysctl.8; are named + the same as the tunables in + /boot/loader.conf. References More information about ACPI may be found in the following locations: The &a.acpi; The ACPI Mailing List Archives The old ACPI Mailing List Archives The ACPI 2.0 Specification - &os; Manual pages: &man.acpi.4;, + &man.acpi.4;, &man.acpi.thermal.4;, &man.acpidump.8;, &man.iasl.8;, - &man.acpidb.8; + and &man.acpidb.8; - DSDT debugging resource. - (Uses Compaq as an example but generally useful.) + DSDT debugging + resource. diff --git a/en_US.ISO8859-1/books/handbook/disks/chapter.xml b/en_US.ISO8859-1/books/handbook/disks/chapter.xml index 182fd40c3d..b92339ed4c 100644 --- a/en_US.ISO8859-1/books/handbook/disks/chapter.xml +++ b/en_US.ISO8859-1/books/handbook/disks/chapter.xml @@ -1,4452 +1,4443 @@ Storage Synopsis This chapter covers the use of disks in &os;. This includes memory-backed disks, network-attached disks, standard SCSI/IDE storage devices, and devices using the USB interface. After reading this chapter, you will know: The terminology &os; uses to describe the organization of data on a physical disk. How to add additional hard disks to a &os; system. How to configure &os; to use USB storage devices. How to set up virtual file systems, such as memory disks. How to use quotas to limit disk space usage. How to encrypt disks to secure them against attackers. How to create and burn CDs and DVDs on &os;. The various storage media options for backups. How to use the backup programs available under &os;. How to backup to floppy disks. What file system snapshots are and how to use them efficiently. Before reading this chapter, you should: Know how to configure and install a new &os; kernel. Device Names The following is a list of physical storage devices supported in &os;, and their associated device names. Physical Disk Naming Conventions Drive type Drive device name IDE hard drives ad IDE CDROM drives acd SCSI hard drives and USB Mass storage devices da SCSI CDROM drives cd Assorted non-standard CDROM drives mcd for Mitsumi CD-ROM and scd for Sony CD-ROM devices Floppy drives fd SCSI tape drives sa IDE tape drives ast Flash drives fla for &diskonchip; Flash device RAID drives aacd for &adaptec; AdvancedRAID, mlxd and mlyd for &mylex;, amrd for AMI &megaraid;, idad for Compaq Smart RAID, twed for &tm.3ware; RAID.
David O'Brien Originally contributed by Adding Disks disks adding This section describes how to add a new SATA disk to a machine that currently only has a single drive. First, turn off the computer and install the drive in the computer following the instructions of the computer, controller, and drive manufacturers. Reboot the system and become root. Inspect /var/run/dmesg.boot to ensure the new disk was found. In this example, the newly added SATA drive will appear as ada1. partitions gpart For this example, a single large partition will be created on the new disk. The GPT partitioning scheme will be used in preference to the older and less versatile MBR scheme. If the disk to be added is not blank, old partition information can be removed with gpart delete. See &man.gpart.8; for details. The partition scheme is created, and then a single partition is added: &prompt.root; gpart create -s GPT ada1 &prompt.root; gpart add -t freebsd-ufs ada1 Depending on use, several smaller partitions may be desired. See &man.gpart.8; for options to create partitions smaller than a whole disk. A file system is created on the new blank disk: &prompt.root; newfs -U /dev/ada1p1 An empty directory is created as a mountpoint, a location for mounting the new disk in the original disk's file system: &prompt.root; mkdir /newdisk Finally, an entry is added to /etc/fstab so the new disk will be mounted automatically at startup: /dev/ada1p1 /newdisk ufs rw 2 2 The new disk can be mounted manually, without restarting the system: &prompt.root; mount /newdisk RAID Software RAID Christopher Shumway Original work by Jim Brown Revised by Concatenated Disk Driver (CCD) Configuration RAIDsoftware RAIDCCD When choosing a mass storage solution, the most important factors to consider are speed, reliability, and cost. It is rare to have all three in balance. Normally a fast, reliable mass storage device is expensive, and to cut back on cost either speed or reliability must be sacrificed. In designing the system described below, cost was chosen as the most important factor, followed by speed, then reliability. Data transfer speed for this system is ultimately constrained by the network. While reliability is very important, the CCD drive described below serves online data that is already fully backed up and which can easily be replaced. Defining the requirements is the first step in choosing a mass storage solution. If the requirements prefer speed or reliability over cost, the solution will differ from the system described in this section. Installing the Hardware In addition to the IDE system disk, three Western Digital 30GB, 5400 RPM IDE disks form the core of the CCD disk described below, providing approximately 90GB of online storage. Ideally, each IDE disk would have its own IDE controller and cable, but to minimize cost, additional IDE controllers were not used. Instead, the disks were configured with jumpers so that each IDE controller has one master, and one slave. Upon reboot, the system BIOS was configured to automatically detect the disks attached. More importantly, &os; detected them on reboot: ad0: 19574MB <WDC WD205BA> [39770/16/63] at ata0-master UDMA33 ad1: 29333MB <WDC WD307AA> [59598/16/63] at ata0-slave UDMA33 ad2: 29333MB <WDC WD307AA> [59598/16/63] at ata1-master UDMA33 ad3: 29333MB <WDC WD307AA> [59598/16/63] at ata1-slave UDMA33 If &os; does not detect all the disks, consult the drive documentation for proper setup and verify that the controller is supported by &os;. Setting Up the CCD The &man.ccd.4; driver takes several identical disks and concatenates them into one logical file system. In order to use &man.ccd.4;, its kernel module must be loaded using &man.ccd.4;. When using a custom kernel, ensure that this line is compiled in: device ccd Before configuring &man.ccd.4;, use &man.bsdlabel.8; to label the disks: bsdlabel -w ad1 auto bsdlabel -w ad2 auto bsdlabel -w ad3 auto This example creates a bsdlabel for ad1c, ad2c and ad3c that spans the entire disk. The next step is to change the disk label type. Use &man.bsdlabel.8; to edit the disks: bsdlabel -e ad1 bsdlabel -e ad2 bsdlabel -e ad3 This opens up the current disk label on each disk with the editor specified by the EDITOR environment variable, typically &man.vi.1;. An unmodified disk label will look something like this: 8 partitions: # size offset fstype [fsize bsize bps/cpg] c: 60074784 0 unused 0 0 0 # (Cyl. 0 - 59597) Add a new e partition for &man.ccd.4; to use. This can usually be copied from the c partition, but the must be 4.2BSD. The disk label should now look something like this: 8 partitions: # size offset fstype [fsize bsize bps/cpg] c: 60074784 0 unused 0 0 0 # (Cyl. 0 - 59597) e: 60074784 0 4.2BSD 0 0 0 # (Cyl. 0 - 59597) Building the File System Now that all the disks are labeled, build the &man.ccd.4; using &man.ccdconfig.8;, with options similar to the following: ccdconfig ccd0 32 0 /dev/ad1e /dev/ad2e /dev/ad3e The use and meaning of each option is described below: The first argument is the device to configure, in this case, /dev/ccd0c. The /dev/ portion is optional. The interleave for the file system, which defines the size of a stripe in disk blocks, each normally 512 bytes. So, an interleave of 32 would be 16,384 bytes. Flags for &man.ccdconfig.8;. For example, to enable drive mirroring, specify a flag. This configuration does not provide mirroring for &man.ccd.4;, so it is set at 0 (zero). The final arguments to &man.ccdconfig.8; are the devices to place into the array. Use the complete path name for each device. After running &man.ccdconfig.8; the &man.ccd.4; is configured and a file system can be installed. Refer to &man.newfs.8; for options, or run: newfs /dev/ccd0c Making it All Automatic Generally, &man.ccd.4; should be configured to automount upon each reboot. To do this, write out the current configuration to /etc/ccd.conf using the following command: ccdconfig -g > /etc/ccd.conf During reboot, the script /etc/rc runs ccdconfig -C if /etc/ccd.conf exists. This automatically configures the &man.ccd.4; so it can be mounted. When booting into single user mode, the following command must be issued to configure the array before the &man.ccd.4; can be mounted: ccdconfig -C To automatically mount the &man.ccd.4;, place an entry for the &man.ccd.4; in /etc/fstab so it will be mounted at boot time: /dev/ccd0c /media ufs rw 2 2 The Vinum Volume Manager RAID software RAID Vinum The Vinum Volume Manager is a block device driver which implements virtual disk drives. It isolates disk hardware from the block device interface and maps data in ways which result in an increase in flexibility, performance and reliability compared to the traditional slice view of disk storage. &man.vinum.4; implements the RAID-0, RAID-1 and RAID-5 models, both individually and in combination. Refer to for more information about &man.vinum.4;. Hardware RAID RAID hardware &os; also supports a variety of hardware RAID controllers. These devices control a RAID subsystem without the need for &os; specific software to manage the array. Using an on-card BIOS, the card controls most of the disk operations. The following is a brief setup description using a Promise IDE RAID controller. When this card is installed and the system is started up, it displays a prompt requesting information. Follow the instructions to enter the card's setup screen and to combine all the attached drives. After doing so, the disks will look like a single drive to &os;. Other RAID levels can be set up accordingly. Rebuilding ATA RAID1 Arrays &os; supports the ability to hot-replace a failed disk in an array. An error indicating a failed disk will appear in /var/log/messages or in the &man.dmesg.8; output: ad6 on monster1 suffered a hard error. ad6: READ command timeout tag=0 serv=0 - resetting ad6: trying fallback to PIO mode ata3: resetting devices .. done ad6: hard error reading fsbn 1116119 of 0-7 (ad6 bn 1116119; cn 1107 tn 4 sn 11)\\ status=59 error=40 ar0: WARNING - mirror lost Use &man.atacontrol.8; to check for further information: &prompt.root; atacontrol list ATA channel 0: Master: no device present Slave: acd0 <HL-DT-ST CD-ROM GCR-8520B/1.00> ATA/ATAPI rev 0 ATA channel 1: Master: no device present Slave: no device present ATA channel 2: Master: ad4 <MAXTOR 6L080J4/A93.0500> ATA/ATAPI rev 5 Slave: no device present ATA channel 3: Master: ad6 <MAXTOR 6L080J4/A93.0500> ATA/ATAPI rev 5 Slave: no device present &prompt.root; atacontrol status ar0 ar0: ATA RAID1 subdisks: ad4 ad6 status: DEGRADED First, detach the ata channel with the failed disk so that it can be safely removed: &prompt.root; atacontrol detach ata3 Replace the disk. Reattach the ata channel: &prompt.root; atacontrol attach ata3 Master: ad6 <MAXTOR 6L080J4/A93.0500> ATA/ATAPI rev 5 Slave: no device present Add the new disk to the array as a spare: &prompt.root; atacontrol addspare ar0 ad6 Rebuild the array: &prompt.root; atacontrol rebuild ar0 It is possible to check on the progress by issuing the following command: &prompt.root; dmesg | tail -10 [output removed] ad6: removed from configuration ad6: deleted from ar0 disk1 ad6: inserted into ar0 disk1 as spare &prompt.root; atacontrol status ar0 ar0: ATA RAID1 subdisks: ad4 ad6 status: REBUILDING 0% completed Wait until this operation completes. Marc Fonvieille Contributed by USB Storage Devices USB disks Many external storage solutions, such as hard drives, USB thumbdrives, and CD/DVD burners, use the Universal Serial Bus (USB). &os; provides support for these devices. Configuration The USB mass storage devices driver, &man.umass.4;, is built into the GENERIC kernel and provides support for USB storage devices. For a custom kernel, be sure that the following lines are present in the kernel configuration file: device scbus device da device pass device uhci device ohci device ehci device usb device umass Since the &man.umass.4; driver uses the SCSI subsystem to access the USB storage devices, any USB device will be seen as a SCSI device by the system. Depending on the USB chipset on the motherboard, device uhci or device ohci is used to provide USB 1.X support. Support for USB 2.0 controllers is provided by device ehci. If the USB device is a CD or DVD burner, &man.cd.4;, must be added to the kernel via the line: device cd Since the burner is seen as a SCSI drive, the driver &man.atapicam.4; should not be used in the kernel configuration. Testing the Configuration To test the USB configuration, plug in the USB device. In the system message buffer, &man.dmesg.8;, the drive should appear as something like: umass0: USB Solid state disk, rev 1.10/1.00, addr 2 GEOM: create disk da0 dp=0xc2d74850 da0 at umass-sim0 bus 0 target 0 lun 0 da0: <Generic Traveling Disk 1.11> Removable Direct Access SCSI-2 device da0: 1.000MB/s transfers da0: 126MB (258048 512 byte sectors: 64H 32S/T 126C) The brand, device node (da0), and other details will differ according to the device. Since the USB device is seen as a SCSI one, camcontrol can be used to list the USB storage devices attached to the system: &prompt.root; camcontrol devlist <Generic Traveling Disk 1.11> at scbus0 target 0 lun 0 (da0,pass0) If the drive comes with a file system, it can be mounted. Refer to for instructions on how to format and create partitions on the USB drive. Allowing untrusted users to mount arbitrary media, by enabling vfs.usermount as described below, should not be considered safe from a security point of view. Most file systems in &os; were not built to safeguard against malicious devices. To make the device mountable as a normal user, one solution is to make all users of the device a member of the operator group using &man.pw.8;. Next, ensure that the operator group is able to read and write the device by adding these lines to /etc/devfs.rules: [localrules=5] add path 'da*' mode 0660 group operator If SCSI disks are installed in the system, change the second line as follows: add path 'da[3-9]*' mode 0660 group operator This will exclude the first three SCSI disks (da0 to da2)from belonging to the operator group. Next, enable the &man.devfs.rules.5; ruleset in /etc/rc.conf: devfs_system_ruleset="localrules" Next, instruct the running kernel to allow regular users to mount file systems. The easiest way is to add the following line to /etc/sysctl.conf: vfs.usermount=1 Since this only takes effect after the next reboot use &man.sysctl.8; to set this variable now. The final step is to create a directory where the file system is to be mounted. This directory needs to be owned by the user that is to mount the file system. One way to do that is for root to create a subdirectory owned by that user as /mnt/username. In the following example, replace username with the login name of the user and usergroup with the user's primary group: &prompt.root; mkdir /mnt/username &prompt.root; chown username:usergroup /mnt/username Suppose a USB thumbdrive is plugged in, and a device /dev/da0s1 appears. If the device is preformatted with a FAT file system, it can be mounted using: &prompt.user; mount -t msdosfs -o -m=644,-M=755 /dev/da0s1 /mnt/username Before the device can be unplugged, it must be unmounted first. After device removal, the system message buffer will show messages similar to the following: umass0: at uhub0 port 1 (addr 2) disconnected (da0:umass-sim0:0:0:0): lost device (da0:umass-sim0:0:0:0): removing device entry GEOM: destroy disk da0 dp=0xc2d74850 umass0: detached Further Reading Beside the Adding Disks and Mounting and Unmounting File Systems sections, reading various manual pages may be also useful: &man.umass.4;, &man.camcontrol.8;, and &man.usbconfig.8; under &os;  8.X or &man.usbdevs.8; under earlier versions of &os;. Mike Meyer Contributed by Creating and Using CD Media CDROMs creating Introduction CD media provide a number of features that differentiate them from conventional disks. Initially, they were not writable by the user. They are designed so that they can be read continuously without delays to move the head between tracks. They are also much easier to transport between systems. CD media do have tracks, but this refers to a section of data to be read continuously and not a physical property of the disk. For example, to produce a CD on &os;, prepare the data files that are going to make up the tracks on the CD, then write the tracks to the CD. ISO 9660 file systems ISO 9660 The ISO 9660 file system was designed to deal with these differences. To overcome the original file system limits, it provides an extension mechanism that allows properly written CDs to exceed those limits while still working with systems that do not support those extensions. sysutils/cdrtools The sysutils/cdrtools port includes &man.mkisofs.8;, a program that can be used to produce a data file containing an ISO 9660 file system. It has options that support various extensions, and is described below. CD burner ATAPI Which tool to use to burn the CD depends on whether the CD burner is ATAPI or something else. ATAPI CD burners use burncd which is part of the base system. SCSI and USB CD burners should use cdrecord from the sysutils/cdrtools port. It is also possible to use cdrecord and other tools for SCSI drives on ATAPI hardware with the ATAPI/CAM module. For CD burning software with a graphical user interface, consider X-CD-Roast or K3b. These tools are available as packages or from the sysutils/xcdroast and sysutils/k3b ports. X-CD-Roast and K3b require the ATAPI/CAM module with ATAPI hardware. <application>mkisofs</application> The sysutils/cdrtools port also installs &man.mkisofs.8;, which produces an ISO 9660 file system that is an image of a directory tree in the &unix; file system name space. The simplest usage is: &prompt.root; mkisofs -o imagefile.iso /path/to/tree file systems ISO 9660 This command creates an imagefile.iso containing an ISO 9660 file system that is a copy of the tree at /path/to/tree. In the process, it maps the file names to names that fit the limitations of the standard ISO 9660 file system, and will exclude files that have names uncharacteristic of ISO file systems. file systems HFS file systems Joliet A number of options are available to overcome these restrictions. In particular, enables the Rock Ridge extensions common to &unix; systems, enables Joliet extensions used by Microsoft systems, and can be used to create HFS file systems used by &macos;. For CDs that are going to be used only on &os; systems, can be used to disable all filename restrictions. When used with , it produces a file system image that is identical to the specified &os; tree, though it may violate the ISO 9660 standard in a number of ways. CDROMs creating bootable The last option of general use is . This is used to specify the location of the boot image for use in producing an El Torito bootable CD. This option takes an argument which is the path to a boot image from the top of the tree being written to the CD. By default, &man.mkisofs.8; creates an ISO image in floppy disk emulation mode, and thus expects the boot image to be exactly 1200, 1440 or 2880 KB in size. Some boot loaders, like the one used by the &os; distribution disks, do not use emulation mode. In this case, should be used. So, if /tmp/myboot holds a bootable &os; system with the boot image in /tmp/myboot/boot/cdboot, this command would produce the image of an ISO 9660 file system as /tmp/bootable.iso: &prompt.root; mkisofs -R -no-emul-boot -b boot/cdboot -o /tmp/bootable.iso /tmp/myboot If md is configured in the kernel, the file system can be mounted as a memory disk with: &prompt.root; mdconfig -a -t vnode -f /tmp/bootable.iso -u 0 &prompt.root; mount -t cd9660 /dev/md0 /mnt One can then verify that /mnt and /tmp/myboot are identical. There are many other options available for &man.mkisofs.8; to fine-tune its behavior. Refer to &man.mkisofs.8; for details. <application>burncd</application> CDROMs burning For an ATAPI CD burner, burncd can be used to burn an ISO image onto a CD. burncd is part of the base system, installed as /usr/sbin/burncd. Usage is very simple, as it has few options: &prompt.root; burncd -f cddevice data imagefile.iso fixate This command will burn a copy of imagefile.iso on cddevice. The default device is /dev/acd0. See &man.burncd.8; for options to set the write speed, eject the CD after burning, and write audio data. <application>cdrecord</application> For systems without an ATAPI CD burner, cdrecord can be used to burn CDs. cdrecord is not part of the base system and must be installed from either the sysutils/cdrtools package or port. Changes to the base system can cause binary versions of this program to fail, possibly resulting in a coaster. It is recommended to either upgrade the port when the system is upgraded, or for users tracking -STABLE, to upgrade the port when a new version becomes available. While cdrecord has many options, basic usage is simple. Burning an ISO 9660 image is done with: &prompt.root; cdrecord dev=device imagefile.iso The tricky part of using cdrecord is finding the to use. To find the proper setting, use which might produce results like this: CDROMs burning &prompt.root; cdrecord -scanbus Cdrecord-Clone 2.01 (i386-unknown-freebsd7.0) Copyright (C) 1995-2004 Jörg Schilling Using libscg version 'schily-0.1' scsibus0: 0,0,0 0) 'SEAGATE ' 'ST39236LW ' '0004' Disk 0,1,0 1) 'SEAGATE ' 'ST39173W ' '5958' Disk 0,2,0 2) * 0,3,0 3) 'iomega ' 'jaz 1GB ' 'J.86' Removable Disk 0,4,0 4) 'NEC ' 'CD-ROM DRIVE:466' '1.26' Removable CD-ROM 0,5,0 5) * 0,6,0 6) * 0,7,0 7) * scsibus1: 1,0,0 100) * 1,1,0 101) * 1,2,0 102) * 1,3,0 103) * 1,4,0 104) * 1,5,0 105) 'YAMAHA ' 'CRW4260 ' '1.0q' Removable CD-ROM 1,6,0 106) 'ARTEC ' 'AM12S ' '1.06' Scanner 1,7,0 107) * This lists the appropriate value for the devices on the list. Locate the CD burner, and use the three numbers separated by commas as the value for . In this case, the CRW device is 1,5,0, so the appropriate input is . Refer to &man.cdrecord.1; for easier ways to specify this value and for information on writing audio tracks and controlling the write speed. Duplicating Audio CDs To duplicate an audio CD, extract the audio data from the CD to a series of files, then write these files to a blank CD. The process is slightly different for ATAPI and SCSI drives. SCSI Drives Use cdda2wav to extract the audio: &prompt.user; cdda2wav -vall -D2,0 -B -Owav Use cdrecord to write the .wav files: &prompt.user; cdrecord -v dev=2,0 -dao -useinfo *.wav Make sure that 2,0 is set appropriately, as described in . ATAPI Drives With the help of the ATAPI/CAM module, cdda2wav can also be used on ATAPI drives. This tool is usually a better choice for most of users, as it supports jitter correction and endianness, than the method proposed below. The ATAPI CD driver makes each track available as /dev/acddtnn, where d is the drive number, and nn is the track number written with two decimal digits, prefixed with zero as needed. So the first track on the first disk is /dev/acd0t01, the second is /dev/acd0t02, the third is /dev/acd0t03, and so on. Make sure the appropriate files exist in /dev. If the entries are missing, force the system to retaste the media: &prompt.root; dd if=/dev/acd0 of=/dev/null count=1 Extract each track using &man.dd.1;, making sure to specify a block size when extracting the files: &prompt.root; dd if=/dev/acd0t01 of=track1.cdr bs=2352 &prompt.root; dd if=/dev/acd0t02 of=track2.cdr bs=2352 ... Burn the extracted files to disk using burncd. Specify that these are audio files, and that burncd should fixate the disk when finished: &prompt.root; burncd -f /dev/acd0 audio track1.cdr track2.cdr ... fixate Duplicating Data CDs It is possible to copy a data CD to an image file that is functionally equivalent to the image file created with &man.mkisofs.8;, and then use it to duplicate any data CD. The example given here assumes that the CDROM device is acd0. Substitute the correct CDROM device. &prompt.root; dd if=/dev/acd0 of=file.iso bs=2048 Now that there is an image, it can be burned to CD as described above. Using Data CDs It is possible to mount and read the data on a standard data CD. By default, &man.mount.8; assumes that a file system is of type ufs. Running this command: &prompt.root; mount /dev/cd0 /mnt will generate an error about Incorrect super block, and will fail to mount the CD. The CD does not use the UFS file system, so attempts to mount it as such will fail. Instead, tell &man.mount.8; that the file system is of type ISO9660 by specifying to &man.mount.8;. For example, to mount the CDROM device, /dev/cd0, under /mnt, use: &prompt.root; mount -t cd9660 /dev/cd0 /mnt Replace /dev/cd0 with the device name for the CD device. Also, executes &man.mount.cd9660.8;, meaning the above command is equivalent to: &prompt.root; mount_cd9660 /dev/cd0 /mnt While data CDROMs from any vendor can be mounted this way, disks with certain ISO 9660 extensions might behave oddly. For example, Joliet disks store all filenames in two-byte Unicode characters. The &os; kernel does not speak Unicode, but the &os; CD9660 driver is able to convert Unicode characters on the fly. If some non-English characters show up as question marks, specify the local charset with . For more information, refer to &man.mount.cd9660.8;. In order to do this character conversion with the help of , the kernel requires the cd9660_iconv.ko module to be loaded. This can be done either by adding this line to loader.conf: cd9660_iconv_load="YES" and then rebooting the machine, or by directly loading the module with &man.kldload.8;. Occasionally, Device not configured will be displayed when trying to mount a CDROM. This usually means that the CDROM drive thinks that there is no disk in the tray, or that the drive is not visible on the bus. It can take a couple of seconds for a CDROM drive to realize that a media is present, so be patient. Sometimes, a SCSI CDROM may be missed because it did not have enough time to answer the bus reset. To resolve this,add the following option to the kernel configuration and rebuild the kernel. options SCSI_DELAY=15000 This tells the SCSI bus to pause 15 seconds during boot, to give the CDROM drive every possible chance to answer the bus reset. Burning Raw Data CDs It is possible to burn a file directly to CD, without creating an ISO 9660 file system. Some people do this for backup purposes. This command runs more quickly than burning a standard CD: &prompt.root; burncd -f /dev/acd1 -s 12 data archive.tar.gz fixate In order to retrieve the data burned to such a CD, the data must be read from the raw device node: &prompt.root; tar xzvf /dev/acd1 This type of disk can not be mounted as a normal CDROM and the data cannot be read under any operating system except &os;. In order to mount the CD, or to share the data with another operating system, &man.mkisofs.8; must be used as described above. Marc Fonvieille Contributed by Using the ATAPI/CAM Driver CD burner ATAPI/CAM driver This driver allows ATAPI devices, such as CD/DVD drives, to be accessed through the SCSI subsystem, and so allows the use of applications like sysutils/cdrdao or &man.cdrecord.1;. To use this driver, add the following line to /boot/loader.conf: atapicam_load="YES" then, reboot the system. Users who prefer to statically compile &man.atapicam.4; support into the kernel, should add this line to the kernel configuration file: device atapicam Ensure the following lines are still in the kernel configuration file: device ata device scbus device cd device pass Then rebuild, install the new kernel, and reboot the machine. During the boot process, the burner should show up, like so: acd0: CD-RW <MATSHITA CD-RW/DVD-ROM UJDA740> at ata1-master PIO4 cd0 at ata1 bus 0 target 0 lun 0 cd0: <MATSHITA CDRW/DVD UJDA740 1.00> Removable CD-ROM SCSI-0 device cd0: 16.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed The drive can now be accessed via the /dev/cd0 device name. For example, to mount a CD-ROM on /mnt, type the following: &prompt.root; mount -t cd9660 /dev/cd0 /mnt As root, run the following command to get the SCSI address of the burner: &prompt.root; camcontrol devlist <MATSHITA CDRW/DVD UJDA740 1.00> at scbus1 target 0 lun 0 (pass0,cd0) In this example, 1,0,0 is the SCSI address to use with &man.cdrecord.1; and other SCSI applications. For more information about ATAPI/CAM and SCSI system, refer to &man.atapicam.4; and &man.cam.4;. Marc Fonvieille Contributed by Andy Polyakov With inputs from Creating and Using DVD Media DVD burning Introduction Compared to the CD, the DVD is the next generation of optical media storage technology. The DVD can hold more data than any CD and is the standard for video publishing. Five physical recordable formats can be defined for a recordable DVD: DVD-R: This was the first DVD recordable format available. The DVD-R standard is defined by the DVD Forum. This format is write once. DVD-RW: This is the rewritable version of the DVD-R standard. A DVD-RW can be rewritten about 1000 times. DVD-RAM: This is a rewritable format which can be seen as a removable hard drive. However, this media is not compatible with most DVD-ROM drives and DVD-Video players as only a few DVD writers support the DVD-RAM format. Refer to for more information on DVD-RAM use. DVD+RW: This is a rewritable format defined by the DVD+RW Alliance. A DVD+RW can be rewritten about 1000 times. DVD+R: This format is the write once variation of the DVD+RW format. A single layer recordable DVD can hold up to 4,700,000,000 bytes which is actually 4.38 GB or 4485 MB as 1 kilobyte is 1024 bytes. A distinction must be made between the physical media and the application. For example, a DVD-Video is a specific file layout that can be written on any recordable DVD physical media such as DVD-R, DVD+R, or DVD-RW. Before choosing the type of media, ensure that both the burner and the DVD-Video player are compatible with the media under consideration. Configuration To perform DVD recording, use &man.growisofs.1;. This command is part of the sysutils/dvd+rw-tools utilities which support all DVD media types. These tools use the SCSI subsystem to access the devices, therefore ATAPI/CAM support must be loaded or statically compiled into the kernel. This support is not needed if the burner uses the USB interface. Refer to for more details on USB device configuration. DMA access must also be enabled for ATAPI devices, by adding the following line to /boot/loader.conf: hw.ata.atapi_dma="1" Before attempting to use dvd+rw-tools, consult the Hardware Compatibility Notes. For a graphical user interface, consider using sysutils/k3b which provides a user friendly interface to &man.growisofs.1; and many other burning tools. Burning Data DVDs Since &man.growisofs.1; is a front-end to mkisofs, it will invoke &man.mkisofs.8; to create the file system layout and perform the write on the DVD. This means that an image of the data does not need to be created before the burning process. To burn to a DVD+R or a DVD-R the data in /path/to/data, use the following command: &prompt.root; growisofs -dvd-compat -Z /dev/cd0 -J -R /path/to/data In this example, is passed to &man.mkisofs.8; to create an ISO 9660 file system with Joliet and Rock Ridge extensions. Refer to &man.mkisofs.8; for more details. For the initial session recording, is used for both single and multiple sessions. Replace /dev/cd0, with the name of the DVD device. Using indicates that the disk will be closed and that the recording will be unappendable. This should also provide better media compatibility with DVD-ROM drives. To burn a pre-mastered image, such as imagefile.iso, use: &prompt.root; growisofs -dvd-compat -Z /dev/cd0=imagefile.iso The write speed should be detected and automatically set according to the media and the drive being used. To force the write speed, use . Refer to &man.growisofs.1; for example usage. In order to support working files larger than 4.38GB, an UDF/ISO-9660 hybrid filesystem must be created by passing to &man.mkisofs.8; and all related programs, such as &man.growisofs.1;. This is required only when creating an ISO image file or when writing files directly to a disk. Since a disk created this way must be mounted as an UDF filesystem with &man.mount.udf.8;, it will be usable only on an UDF aware operating system. Otherwise it will look as if it contains corrupted files. To create this type of ISO file: &prompt.user; mkisofs -R -J -udf -iso-level 3 -o imagefile.iso /path/to/data To burn files directly to a disk: &prompt.root; growisofs -dvd-compat -udf -iso-level 3 -Z /dev/cd0 -J -R /path/to/data When an ISO image already contains large files, no additional options are required for &man.growisofs.1; to burn that image on a disk. Be sure to use an up-to-date version of sysutils/cdrtools, which contains &man.mkisofs.8;, as an older version may not contain large files support. If the latest version does not work, install sysutils/cdrtools-devel and read its &man.mkisofs.8;. Burning a DVD-Video DVD DVD-Video A DVD-Video is a specific file layout based on the ISO 9660 and micro-UDF (M-UDF) specifications. Since DVD-Video presents a specific data structure hierarchy, a particular program such as multimedia/dvdauthor is needed to author the DVD. If an image of the DVD-Video file system already exists, it can be burned in the same way as any other image. If dvdauthor was used to make the DVD and the result is in /path/to/video, the following command should be used to burn the DVD-Video: &prompt.root; growisofs -Z /dev/cd0 -dvd-video /path/to/video is passed to &man.mkisofs.8; to instruct it to create a DVD-Video file system layout. This option implies the &man.growisofs.1; option. Using a DVD+RW DVD DVD+RW Unlike CD-RW, a virgin DVD+RW needs to be formatted before first use. It is recommended to let &man.growisofs.1; take care of this automatically whenever appropriate. However, it is possible to use dvd+rw-format to format the DVD+RW: &prompt.root; dvd+rw-format /dev/cd0 Only perform this operation once and keep in mind that only virgin DVD+RW medias need to be formatted. Once formatted, the DVD+RW can be burned as usual. To burn a totally new file system and not just append some data onto a DVD+RW, the media does not need to be blanked first. Instead, write over the previous recording like this: &prompt.root; growisofs -Z /dev/cd0 -J -R /path/to/newdata The DVD+RW format supports appending data to a previous recording. This operation consists of merging a new session to the existing one as it is not considered to be multi-session writing. &man.growisofs.1; will grow the ISO 9660 file system present on the media. For example, to append data to a DVD+RW, use the following: &prompt.root; growisofs -M /dev/cd0 -J -R /path/to/nextdata The same &man.mkisofs.8; options used to burn the initial session should be used during next writes. Use for better media compatibility with DVD-ROM drives. When using DVD+RW, this option will not prevent the addition of data. To blank the media, use: &prompt.root; growisofs -Z /dev/cd0=/dev/zero Using a DVD-RW DVD DVD-RW A DVD-RW accepts two disc formats: incremental sequential and restricted overwrite. By default, DVD-RW discs are in sequential format. A virgin DVD-RW can be directly written without being formatted. However, a non-virgin DVD-RW in sequential format needs to be blanked before writing a new initial session. To blank a DVD-RW in sequential mode: &prompt.root; dvd+rw-format -blank=full /dev/cd0 A full blanking using will take about one hour on a 1x media. A fast blanking can be performed using , if the DVD-RW will be recorded in Disk-At-Once (DAO) mode. To burn the DVD-RW in DAO mode, use the command: &prompt.root; growisofs -use-the-force-luke=dao -Z /dev/cd0=imagefile.iso Since &man.growisofs.1; automatically attempts to detect fast blanked media and engage DAO write, should not be required. One should instead use restricted overwrite mode with any DVD-RW as this format is more flexible than the default of incremental sequential. To write data on a sequential DVD-RW, use the same instructions as for the other DVD formats: &prompt.root; growisofs -Z /dev/cd0 -J -R /path/to/data To append some data to a previous recording, use with &man.growisofs.1;. However, if data is appended on a DVD-RW in incremental sequential mode, a new session will be created on the disc and the result will be a multi-session disc. A DVD-RW in restricted overwrite format does not need to be blanked before a new initial session. Instead, overwrite the disc with . It is also possible to grow an existing ISO 9660 file system written on the disc with . The result will be a one-session DVD. To put a DVD-RW in restricted overwrite format, the following command must be used: &prompt.root; dvd+rw-format /dev/cd0 To change back to sequential format, use: &prompt.root; dvd+rw-format -blank=full /dev/cd0 Multi-Session Few DVD-ROM drives support multi-session DVDs and most of the time only read the first session. DVD+R, DVD-R and DVD-RW in sequential format can accept multiple sessions. The notion of multiple sessions does not exist for the DVD+RW and the DVD-RW restricted overwrite formats. Using the following command after an initial non-closed session on a DVD+R, DVD-R, or DVD-RW in sequential format, will add a new session to the disc: &prompt.root; growisofs -M /dev/cd0 -J -R /path/to/nextdata Using this command with a DVD+RW or a DVD-RW in restricted overwrite mode will append data while merging the new session to the existing one. The result will be a single-session disc. Use this method to add data after an initial write on these types of media. Since some space on the media is used between each session to mark the end and start of sessions, one should add sessions with a large amount of data to optimize media space. The number of sessions is limited to 154 for a DVD+R, about 2000 for a DVD-R, and 127 for a DVD+R Double Layer. For More Information To obtain more information about a DVD, use dvd+rw-mediainfo /dev/cd0 while the disc in the specified drive. More information about dvd+rw-tools can be found in &man.growisofs.1;, on the dvd+rw-tools web site, and in the cdwrite mailing list archives. When creating a problem report related to the use of dvd+rw-tools, always include the output of dvd+rw-mediainfo. Using a DVD-RAM DVD DVD-RAM Configuration DVD-RAM writers can use either a SCSI or ATAPI interface. For ATAPI devices, DMA access has to be enabled by adding the following line to /boot/loader.conf: hw.ata.atapi_dma="1" Preparing the Media A DVD-RAM can be seen as a removable hard drive. Like any other hard drive, the DVD-RAM must be formatted before it can be used. In this example, the whole disk space will be formatted with a standard UFS2 file system: &prompt.root; dd if=/dev/zero of=/dev/acd0 bs=2k count=1 &prompt.root; bsdlabel -Bw acd0 &prompt.root; newfs /dev/acd0 The DVD device, acd0, must be changed according to the configuration. Using the Media Once the DVD-RAM has been formatted, it can be mounted as a normal hard drive: &prompt.root; mount /dev/acd0 /mnt Once mounted, the DVD-RAM will be both readable and writeable. Julio Merino Original work by Martin Karlsson Rewritten by Creating and Using Floppy Disks Storing data on floppy disks is sometimes useful, for example when one does not have any other removable storage media or when one needs to transfer small amounts of data to another computer. This section explains how to use floppy disks in &os;. It covers formatting and usage of 3.5inch DOS floppies, but the concepts are similar for other floppy disk formats. Formatting Floppies The Device Floppy disks are accessed through entries in /dev, just like other devices. To access the raw floppy disk, simply use /dev/fdN. Formatting A floppy disk needs to be low-level formatted before it can be used. This is usually done by the vendor, but formatting is a good way to check media integrity. Although it is possible to force other disk sizes, 1440kB is what most floppy disks are designed for. To low-level format the floppy disk, use &man.fdformat.1;. This utility expects the device name as an argument. Make note of any error messages, as these can help determine if the disk is good or bad. Formatting Floppy Disks To format the floppy, insert a new 3.5inch floppy disk into the first floppy drive and issue: &prompt.root; /usr/sbin/fdformat -f 1440 /dev/fd0 The Disk Label After low-level formatting the disk, a disk label needs to placed on it. This disk label will be destroyed later, but it is needed by the system to determine the size of the disk and its geometry. The new disk label will take over the whole disk and will contain all the proper information about the geometry of the floppy. The geometry values for the disk label are listed in /etc/disktab. To write the disk label, use &man.bsdlabel.8;: &prompt.root; /sbin/bsdlabel -B -w /dev/fd0 fd1440 The File System The floppy is now ready to be high-level formatted. This will place a new file system on it so that &os; can read and write to the disk. Since creating the new file system destroys the disk label, the disk label needs to be recreated whenever the disk is reformatted. The floppy's file system can be either UFS or FAT. FAT is generally a better choice for floppies. To put a new file system on the floppy, issue: &prompt.root; /sbin/newfs_msdos /dev/fd0 The disk is now ready for use. Using the Floppy To use the floppy, mount it with &man.mount.msdosfs.8;. One can also use emulators/mtools from the Ports Collection. Creating and Using Data Tapes tape media Tape technology has continued to evolve but is less likely to be used in a modern system. Modern backup systems tend to use off site combined with local removable disk drive technologies. Still, &os; will support any tape drive that uses SCSI, such as LTO and older devices such as DAT. There is limited support for SATA and USB tape drives. Serial Access with &man.sa.4; tape drives &os; uses the &man.sa.4; driver, providing /dev/sa0, /dev/nsa0, and /dev/esa0. In normal use, only /dev/sa0 is needed. /dev/nsa0 is the same physical drive as /dev/sa0 but does not rewind the tape after writing a file. This allows writing more than one file to a tape. Using /dev/esa0 ejects the tape after the device is closed, if applicable. Controlling the Tape Drive with &man.mt.1; tape media mt &man.mt.1; is the &os; utility for controlling other operations of the tape drive, such as seeking through files on a tape or writing tape control marks to the tape. For example, the first three files on a tape can be preserved by skipping past them before writing a new file: &prompt.root; mt -f /dev/nsa0 fsf 3 Using &man.tar.1; to Read and Write Tape Backups An example of writing a single file to tape using &man.tar.1;: &prompt.root; tar cvf /dev/sa0 file Recovering files from a &man.tar.1; archive on tape into the current directory: &prompt.root; tar xvf /dev/sa0 Using &man.dump.8; and &man.restore.8; to Create and Restore Backups A simple backup of /usr with &man.dump.8;: &prompt.root; dump -0aL -b64 -f /dev/nsa0 /usr Interactively restoring files from a &man.dump.8; file on tape into the current directory: &prompt.root; restore -i -f /dev/nsa0 Other Tape Software Higher-level programs are available to simplify tape backup. The most popular are Amanda and Bacula. These programs aim to make backups easier and more convenient, or to automate complex backups of multiple machines. The Ports Collection contains both these and other tape utility applications. Backups to Floppies Can I Use Floppies for Backing Up My Data? backup floppies floppy disks Floppy disks are not a suitable media for making backups as: The media is unreliable, especially over long periods of time. Backing up and restoring is very slow. They have a very limited capacity. However, if no other method of backing up data is available, floppy disks are better than no backup at all. When backing up to floppy disks, ensure the floppies are of good quality. Floppies that have been lying around the office for a couple of years are a bad choice. Ideally, use new ones from a reputable manufacturer. So How Do I Backup My Data to Floppies? The best way to backup to floppy disk is to use &man.tar.1; with (multi-volume), which allows backups to span multiple floppies. To backup all the files in the current directory and sub-directory, use this as root: &prompt.root; tar Mcvf /dev/fd0 * When the first floppy is full, &man.tar.1; will prompt to insert the next volume, which in this case is the next floppy disk: Prepare volume #2 for /dev/fd0 and hit return: This is repeated, with the volume number incrementing, until all the specified files have been archived. Can I Compress My Backups? tar gzip compression Unfortunately, &man.tar.1; does not support for multi-volume archives. Instead, &man.gzip.1; all the files, &man.tar.1; them to the floppies, then &man.gunzip.1; the files. How Do I Restore My Backups? To restore the entire archive use: &prompt.root; tar Mxvf /dev/fd0 There are two methods to restore only specific files. The first is to insert the first floppy and use: &prompt.root; tar Mxvf /dev/fd0 filename &man.tar.1; will prompt to insert subsequent floppies until it finds the required file. Alternatively, if the floppy containing the file is known, insert that floppy and use the same command. If the first file on the floppy is a continuation from the previous one, &man.tar.1; will warn that it cannot restore it, even if you have not asked it to. Lowell Gilbert Original work by Backup Strategies The first requirement in devising a backup plan is to make sure that all of the following problems are covered: Disk failure. Accidental file deletion. Random file corruption. Complete machine destruction, say by fire, including destruction of any on-site backups. Some systems will be best served by having each of these problems covered by a completely different technique. Except for strictly personal systems with low-value data, it is unlikely that one technique will cover all of them. Some possible techniques include: Archives of the whole system, backed up onto permanent, off-site media. This provides protection against all of the problems listed above, but is slow and inconvenient to restore from. Copies of the backups can be stored on site or online, but there will still be inconveniences in restoring files, especially for non-privileged users. Filesystem snapshots, which are really only helpful in the accidental file deletion scenario, but can be very helpful in that case, as well as quick and easy to deal with. Copies of whole file systems or disks which can be created with a periodic net/rsync of the whole machine. This is generally most useful in networks with unique requirements. For general protection against disk failure, this is usually inferior to RAID. For restoring accidentally deleted files, it can be comparable to UFS snapshots. RAID, which minimizes or avoids downtime when a disk fails at the expense of having to deal with disk failures more often, because there are more disks, albeit at a much lower urgency. Checking fingerprints of files using &man.mtree.8;. Although this is not a backup, this technique indicates when one needs to resort to backups. This is particularly important for offline backups, and should be checked periodically. It is quite easy to come up with more techniques, many of them variations on the ones listed above. Specialized requirements usually lead to specialized techniques. For example, backing up a live database usually requires a method particular to the database software as an intermediate step. The important thing is to know which dangers should be protected against, and how each will be handled. Backup Basics The major backup programs built into &os; are &man.dump.8;, &man.tar.1;, &man.cpio.1;, and &man.pax.1;. Dump and Restore backup software dump / restore dump restore The traditional &unix; backup programs are dump and restore. They operate on the drive as a collection of disk blocks, below the abstractions of files, links and directories that are created by the file systems. Unlike other backup software, dump backs up an entire file system on a device. It is unable to backup only part of a file system or a directory tree that spans more than one file system. dump does not write files and directories, but rather writes the raw data blocks that comprise files and directories. When used to extract data, restore stores temporary files in /tmp/ by default. When using a recovery disk with a small /tmp, set TMPDIR to a directory with more free space in order for the restore to succeed. If dump is used on the root directory, it will not back up /home, /usr or many other directories since these are typically mount points for other file systems or symbolic links into those file systems. dump has quirks that remain from its early days in Version 6 of AT&T &unix;,circa 1975. The default parameters are suitable for 9-track tapes (6250 bpi), not the high-density media available today (up to 62,182 ftpi). These defaults must be overridden on the command line to utilize the capacity of current tape drives. .rhosts It is also possible to backup data across the network to a tape drive attached to another computer with rdump and rrestore. Both programs rely upon &man.rcmd.3; and &man.ruserok.3; to access the remote tape drive. Therefore, the user performing the backup must be listed in .rhosts on the remote computer. The arguments to rdump and rrestore must be suitable to use on the remote computer. For example, to rdump from a &os; computer to an Exabyte tape drive connected to a host called komodo, use: &prompt.root; /sbin/rdump 0dsbfu 54000 13000 126 komodo:/dev/nsa8 /dev/da0a 2>&1 There are security implications to allowing .rhosts authentication, so use with caution. It is also possible to use dump and restore in a more secure fashion over ssh. Using <command>dump</command> over <application>ssh</application> &prompt.root; /sbin/dump -0uan -f - /usr | gzip -2 | ssh -c blowfish \ targetuser@targetmachine.example.com dd of=/mybigfiles/dump-usr-l0.gz Or, use the built-in RSH: Using <command>dump</command> over <application>ssh</application> with <envar>RSH</envar> Set &prompt.root; env RSH=/usr/bin/ssh /sbin/dump -0uan -f targetuser@targetmachine.example.com:/dev/sa0 /usr <command>tar</command> backup software tar &man.tar.1; also dates back to Version 6 of AT&T &unix;, circa 1975. tar operates in cooperation with the file system and writes files and directories to tape. tar does not support the full range of options that are available from &man.cpio.1;, but it does not require the unusual command pipeline that cpio uses. tar To tar to an Exabyte tape drive connected to a host called komodo: &prompt.root; tar cf - . | rsh komodo dd of=tape-device obs=20b When backing up over an insecure network, instead use ssh. <command>cpio</command> backup software cpio &man.cpio.1; is the original &unix; file interchange tape program for magnetic media. cpio includes options to perform byte-swapping, write a number of different archive formats, and pipe the data to other programs. This last feature makes cpio an excellent choice for installation media. cpio does not know how to walk the directory tree and a list of files must be provided through stdin. cpio Since cpio does not support backups across the network, use a pipeline and ssh to send the data to a remote tape drive. &prompt.root; for f in directory_list; do find $f >> backup.list done &prompt.root; cpio -v -o --format=newc < backup.list | ssh user@host "cat > backup_device" Where directory_list is the list of directories to back up, user@host is the user/hostname combination that will be performing the backups, and backup_device is where the backups should be written to, such as /dev/nsa0). <command>pax</command> backup software pax pax POSIX IEEE &man.pax.1; is the IEEE/&posix; answer to tar and cpio. Over the years the various versions of tar and cpio have become slightly incompatible. So rather than fight it out to fully standardize them, &posix; created a new archive utility. pax attempts to read and write many of the various cpio and tar formats, plus new formats of its own. Its command set more resembles cpio than tar. <application>Amanda</application> backup software Amanda Amanda Amanda (Advanced Maryland Network Disk Archiver) is a client/server backup system, rather than a single program. An Amanda server will backup to a single tape drive any number of computers that have Amanda clients and a network connection to the Amanda server. A common problem at sites with a number of large disks is that the length of time required to backup to data directly to tape exceeds the amount of time available for the task. Amanda solves this problem by using a holding disk to backup several file systems at the same time. Amanda creates archive sets: a group of tapes used over a period of time to create full backups of all the file systems listed in Amanda's configuration file. The archive set also contains nightly incremental, or differential, backups of all the file systems. Restoring a damaged file system requires the most recent full backup and the incremental backups. The configuration file provides fine grained control of backups and the network traffic that Amanda generates. Amanda will use any of the above backup programs to write the data to tape. Amanda is not installed by but is available as either a port or package. Do Nothing Do nothing is not a computer program, but it is the most widely used backup strategy. There are no initial costs. There is no backup schedule to follow. Just say no. If something happens to your data, grin and bear it! If your time and data is worth little to nothing, then Do nothing is the most suitable backup program for the computer. But beware, &os; is a useful tool and over time it can be used to create a valuable collection of files. Do nothing is the correct backup method for /usr/obj and other directory trees that can be exactly recreated by the computer. An example is the files that comprise the HTML or &postscript; version of this Handbook. These document formats have been created from XML input files. Creating backups of the HTML or &postscript; files is not necessary if the XML files are backed up regularly. Which Backup Program Is Best? LISA &man.dump.8; Period. Elizabeth D. Zwicky torture tested all the backup programs discussed here. The clear choice for preserving all your data and all the peculiarities of &unix; file systems is dump. Elizabeth created file systems containing a large variety of unusual conditions (and some not so unusual ones) and tested each program by doing a backup and restore of those file systems. The peculiarities included: files with holes, files with holes and a block of nulls, files with funny characters in their names, unreadable and unwritable files, devices, files that change size during the backup, files that are created/deleted during the backup and more. She presented the results at LISA V in Oct. 1991. See torture-testing Backup and Archive Programs. Emergency Restore Procedure Before the Disaster There are four steps which should be performed in preparation for any disaster that may occur. bsdlabel First, print the bsdlabel of each disk using a command such as bsdlabel da0 | lpr. Also print a copy of /etc/fstab and all boot messages. livefs CD Second, burn a livefs CD. This CD contains support for booting into a &os; livefs rescue mode, allowing the user to perform many tasks like running &man.dump.8;, &man.restore.8;, &man.fdisk.8;, &man.bsdlabel.8;, &man.newfs.8;, &man.mount.8;, and more. The livefs CD image for &os;/&arch.i386; &rel2.current;-RELEASE is available from . Livefs CD images are not available for &os; &rel.current;-RELEASE and later. In addition to the CDROM installation images, flash drive installation images may be used to recover a system. The memstick image for &os;/&arch.i386; &rel.current;-RELEASE is available from . Third, create backup tapes regularly. Any changes that made after the last backup may be irretrievably lost. Write-protect the backup media. Fourth, test the livefs CD and the backups. Make notes of the procedure. Store these notes with the CD, the printouts, and the backups. These notes may prevent the inadvertent destruction of the backups while under the stress of performing an emergency recovery. For an added measure of security, store an extra livefs CD and the latest backup at a remote location, where a remote location is not the basement of the same building. A remote location should be physically separated from the computers and disk drives by a significant distance. After the Disaster First, determine if the hardware survived. Thanks to regular, off-site backups, there is no need to worry about the software. If the hardware has been damaged, the parts should be replaced before attempting to use the computer. If the hardware is okay, insert the livefs CD and boot the computer. The original install menu will be displayed on the screen. Select the correct country, then choose Fixit -- Repair mode with CDROM/DVD/floppy or start a shell. then select CDROM/DVD -- Use the live filesystem CDROM/DVD. restore and the other needed programs are located in /mnt2/rescue. Recover each file system separately. mount root partition bsdlabel newfs Try to mount the root partition of the first disk using mount /dev/da0a /mnt. If the bsdlabel was damaged, use bsdlabel to re-partition and label the disk to match the label that was printed and saved. Use newfs to re-create the file systems. Re-mount the root partition of the disk read-write using mount -u -o rw /mnt. Use the backups to recover the data for this file system. Unmount the file system with umount /mnt. Repeat for each file system that was damaged. Once the system is running, backup the data onto new media as whatever caused the crash or data loss may strike again. Another hour spent now may save further distress later. Marc Fonvieille Reorganized and enhanced by Network, Memory, and File-Backed File Systems virtual disks disks virtual In addition to physical disks such as floppies, CDs, and hard drives, &os; also supports virtual disks. NFS Coda disks memory These include network file systems such as the Network File System and Coda, memory-based file systems, and file-backed file systems. According to the &os; version, the tools used for the creation and use of file-backed and memory-based file systems differ. Use &man.devfs.5; to allocate device nodes transparently for the user. File-Backed File System disks file-backed &man.mdconfig.8; is used to configure and enable memory disks, &man.md.4;, under &os;. To use &man.mdconfig.8;, &man.md.4; must be first loaded. When using a custom kernel configuration file, ensure it includes this line: device md &man.mdconfig.8; supports several types of memory backed virtual disks: memory disks allocated with &man.malloc.9; and memory disks using a file or swap space as backing. One possible use is the mounting of CD images. To mount an existing file system image: Using <command>mdconfig</command> to Mount an Existing File System Image &prompt.root; mdconfig -a -t vnode -f diskimage -u 0 &prompt.root; mount /dev/md0 /mnt To create a new file system image with &man.mdconfig.8;: Creating a New File-Backed Disk with <command>mdconfig</command> &prompt.root; dd if=/dev/zero of=newimage bs=1k count=5k 5120+0 records in 5120+0 records out &prompt.root; mdconfig -a -t vnode -f newimage -u 0 &prompt.root; bsdlabel -w md0 auto &prompt.root; newfs md0a /dev/md0a: 5.0MB (10224 sectors) block size 16384, fragment size 2048 using 4 cylinder groups of 1.25MB, 80 blks, 192 inodes. super-block backups (for fsck -b #) at: 160, 2720, 5280, 7840 &prompt.root; mount /dev/md0a /mnt &prompt.root; df /mnt Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/md0a 4710 4 4330 0% /mnt If unit number is not specified with , &man.mdconfig.8; uses the &man.md.4; automatic allocation to select an unused device. The name of the allocated unit will be output to stdout, such as md4. Refer to &man.mdconfig.8; for more details about. While &man.mdconfig.8; is useful, it takes several command lines to create a file-backed file system. &os; also comes with &man.mdmfs.8; which automatically configures a &man.md.4; disk using &man.mdconfig.8;, puts a UFS file system on it using &man.newfs.8;, and mounts it using &man.mount.8;. For example, to create and mount the same file system image as above, type the following: Configure and Mount a File-Backed Disk with <command>mdmfs</command> &prompt.root; dd if=/dev/zero of=newimage bs=1k count=5k 5120+0 records in 5120+0 records out &prompt.root; mdmfs -F newimage -s 5m md0 /mnt &prompt.root; df /mnt Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/md0 4718 4 4338 0% /mnt When is used without a unit number, &man.mdmfs.8; uses the &man.md.4; auto-unit feature to automatically select an unused device. For more details about &man.mdmfs.8;, refer to its manual page. Memory-Based File System disks memory file system For a memory-based file system, swap backing should normally be used. This does not mean that the memory disk will be swapped out to disk by default, but rather that the memory disk will be allocated from a memory pool which can be swapped out to disk if needed. It is also possible to create memory-based disks which are &man.malloc.9; backed, but using large malloc backed memory disks can result in a system panic if the kernel runs out of memory. Creating a New Memory-Based Disk with <command>mdconfig</command> &prompt.root; mdconfig -a -t swap -s 5m -u 1 &prompt.root; newfs -U md1 /dev/md1: 5.0MB (10240 sectors) block size 16384, fragment size 2048 using 4 cylinder groups of 1.27MB, 81 blks, 192 inodes. with soft updates super-block backups (for fsck -b #) at: 160, 2752, 5344, 7936 &prompt.root; mount /dev/md1 /mnt &prompt.root; df /mnt Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/md1 4718 4 4338 0% /mnt Creating a New Memory-Based Disk with <command>mdmfs</command> &prompt.root; mdmfs -s 5m md2 /mnt &prompt.root; df /mnt Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/md2 4846 2 4458 0% /mnt Detaching a Memory Disk from the System disks detaching a memory disk When a memory-based or file-based file system is no longer in use, its resources should be released back to the system. First, unmount the file system, then use &man.mdconfig.8; to detach the disk from the system and release the resources. For example, to detach and free all resources used by /dev/md4: &prompt.root; mdconfig -d -u 4 It is possible to list information about configured &man.md.4; devices by running mdconfig -l. Tom Rhodes Contributed by File System Snapshots file systems snapshots &os; offers a feature in conjunction with Soft Updates: file system snapshots. UFS snapshots allow a user to create images of specified file systems, and treat them as a file. Snapshot files must be created in the file system that the action is performed on, and a user may create no more than 20 snapshots per file system. Active snapshots are recorded in the superblock so they are persistent across unmount and remount operations along with system reboots. When a snapshot is no longer required, it can be removed using &man.rm.1;. While snapshots may be removed in any order, all the used space may not be acquired because another snapshot will possibly claim some of the released blocks. The un-alterable file flag is set by &man.mksnap.ffs.8; after initial creation of a snapshot file. &man.unlink.1; makes an exception for snapshot files since it allows them to be removed. Snapshots are created using &man.mount.8;. To place a snapshot of /var in the file /var/snapshot/snap, use the following command: &prompt.root; mount -u -o snapshot /var/snapshot/snap /var Alternatively, use &man.mksnap.ffs.8; to create the snapshot: &prompt.root; mksnap_ffs /var /var/snapshot/snap One can find snapshot files on a file system, such as /var, using &man.find.1;: &prompt.root; find /var -flags snapshot Once a snapshot has been created, it has several uses: Some administrators will use a snapshot file for backup purposes, because the snapshot can be transferred to CDs or tape. The file system integrity checker, &man.fsck.8;, may be run on the snapshot. Assuming that the file system was clean when it was mounted, this should always provide a clean and unchanging result. Running &man.dump.8; on the snapshot will produce a dump file that is consistent with the file system and the timestamp of the snapshot. &man.dump.8; can also take a snapshot, create a dump image, and then remove the snapshot in one command by using . The snapshot can be mounted as a frozen image of the file system. To &man.mount.8; the snapshot /var/snapshot/snap run: &prompt.root; mdconfig -a -t vnode -f /var/snapshot/snap -u 4 &prompt.root; mount -r /dev/md4 /mnt The frozen /var is now available through /mnt. Everything will initially be in the same state it was during the snapshot creation time. The only exception is that any earlier snapshots will appear as zero length files. To unmount the snapshot, use: &prompt.root; umount /mnt &prompt.root; mdconfig -d -u 4 For more information about and file system snapshots, including technical papers, visit Marshall Kirk McKusick's website at . File System Quotas accounting disk space disk quotas Quotas are an optional feature of the operating system that can be used to limit the amount of disk space or the number of files a user or members of a group may allocate on a per-file system basis. This is used most often on timesharing systems where it is desirable to limit the amount of resources any one user or group of users may allocate. This prevents one user or group of users from consuming all of the available disk space. Configuring the System to Enable Disk Quotas Before using disk quotas, quota support must be added to the kernel by adding the following line to the kernel configuration file: options QUOTA The GENERIC kernel does not have this enabled by default, so a custom kernel must be compiled in order to use disk quotas. Refer to for more information on kernel configuration. Next, enable disk quotas in /etc/rc.conf: quota_enable="YES" disk quotas checking For finer control over quota startup, an additional configuration variable is available. Normally on bootup, the quota integrity of each file system is checked by &man.quotacheck.8;. This program insures that the data in the quota database properly reflects the data on the file system. This is a time consuming process that will significantly affect the time the system takes to boot. To skip this step, add this variable to /etc/rc.conf: check_quotas="NO" Finally, edit /etc/fstab to enable disk quotas on a per-file system basis. This is when user or group quotas can be enabled on the file systems. To enable per-user quotas on a file system, add to the options field in the /etc/fstab entry for the file system to enable quotas on. For example: /dev/da1s2g /home ufs rw,userquota 1 2 To enable group quotas, instead use . To enable both user and group quotas, change the entry as follows: /dev/da1s2g /home ufs rw,userquota,groupquota 1 2 By default, the quota files are stored in the root directory of the file system as quota.user and quota.group. Refer to &man.fstab.5; for more information. Even though an alternate location for the quota files can be specified, this is not recommended because the various quota utilities do not seem to handle this properly. Once the configuration is complete, reboot the system with the new kernel. /etc/rc will automatically run the appropriate commands to create the initial quota files for all of the quotas enabled in /etc/fstab. There is no need to manually create any zero length quota files. In the normal course of operations, there should be no need to manually run &man.quotacheck.8;, &man.quotaon.8;, or &man.quotaoff.8;. However, one should read their manual pages to be familiar with their operation. Setting Quota Limits disk quotas limits Once the system has been configured to enable quotas, verify they really are enabled by running: &prompt.root; quota -v There should be a one line summary of disk usage and current quota limits for each file system that quotas are enabled on. The system is now ready to be assigned quota limits with &man.edquota.8;. Several options are available to enforce limits on the amount of disk space a user or group may allocate, and how many files they may create. Allocations can be limited based on disk space (block quotas), number of files (inode quotas), or a combination of both. Each limits is further broken down into two categories: hard and soft limits. hard limit A hard limit may not be exceeded. Once a user reaches a hard limit, no further allocations can be made on that file system by that user. For example, if the user has a hard limit of 500 kbytes on a file system and is currently using 490 kbytes, the user can only allocate an additional 10 kbytes. Attempting to allocate an additional 11 kbytes will fail. soft limit Soft limits can be exceeded for a limited amount of time, known as the grace period, which is one week by default. If a user stays over their limit longer than the grace period, the soft limit turns into a hard limit and no further allocations are allowed. When the user drops back below the soft limit, the grace period is reset. The following is an example output from &man.edquota.8;. When &man.edquota.8; is invoked, the editor specified by EDITOR is opened in order to edit the quota limits. The default editor is set to vi. &prompt.root; edquota -u test Quotas for user test: /usr: kbytes in use: 65, limits (soft = 50, hard = 75) inodes in use: 7, limits (soft = 50, hard = 60) /usr/var: kbytes in use: 0, limits (soft = 50, hard = 75) inodes in use: 0, limits (soft = 50, hard = 60) There are normally two lines for each file system that has quotas enabled. One line represents the block limits and the other represents the inode limits. Change the value to modify the quota limit. For example, to raise this user's block limit from a soft limit of 50 and a hard limit of 75 to a soft limit of 500 and a hard limit of 600, change: /usr: kbytes in use: 65, limits (soft = 50, hard = 75) to: /usr: kbytes in use: 65, limits (soft = 500, hard = 600) The new quota limits take affect upon exiting the editor. Sometimes it is desirable to set quota limits on a range of UIDs. This can be done by passing to &man.edquota.8;. First, assign the desired quota limit to a user, then run edquota -p protouser startuid-enduid. For example, if test has the desired quota limits, the following command will duplicate those quota limits for UIDs 10,000 through 19,999: &prompt.root; edquota -p test 10000-19999 For more information, refer to &man.edquota.8;. Checking Quota Limits and Disk Usage disk quotas checking Either &man.quota.1; or &man.repquota.8; can be used to check quota limits and disk usage. To check individual user or group quotas and disk usage, use &man.quota.1;. A user may only examine their own quota and the quota of a group they are a member of. Only the superuser may view all user and group quotas. To get a summary of all quotas and disk usage for file systems with quotas enabled, use &man.repquota.8;. The following is sample output from quota -v for a user that has quota limits on two file systems. Disk quotas for user test (uid 1002): Filesystem usage quota limit grace files quota limit grace /usr 65* 50 75 5days 7 50 60 /usr/var 0 50 75 0 50 60 grace period In this example, the user is currently 15 kbytes over the soft limit of 50 kbytes on /usr and has 5 days of grace period left. The asterisk * indicates that the user is currently over the quota limit. Normally, file systems that the user is not using any disk space on will not show in the output of &man.quota.1;, even if the user has a quota limit assigned for that file system. Use to display those file systems, such as /usr/var in the above example. Quotas over NFS NFS Quotas are enforced by the quota subsystem on the NFS server. The &man.rpc.rquotad.8; daemon makes quota information available to &man.quota.1; on NFS clients, allowing users on those machines to see their quota statistics. Enable rpc.rquotad in /etc/inetd.conf like so: rquotad/1 dgram rpc/udp wait root /usr/libexec/rpc.rquotad rpc.rquotad Now restart inetd: &prompt.root; service inetd restart Lucky Green Contributed by
shamrock@cypherpunks.to
 Encrypting Disk Partitions disks encrypting &os; offers excellent online protections against unauthorized data access. File permissions and Mandatory Access Control (MAC) help prevent unauthorized users from accessing data while the operating system is active and the computer is powered up. However, the permissions enforced by the operating system are irrelevant if an attacker has physical access to a computer and can move the computer's hard drive to another system to copy and analyze the data. Regardless of how an attacker may have come into possession of a hard drive or powered-down computer, both the GEOM Based Disk Encryption (gbde) and geli cryptographic subsystems in &os; are able to protect the data on the computer's file systems against even highly-motivated attackers with significant resources. Unlike cumbersome encryption methods that encrypt only individual files, gbde and geli transparently encrypt entire file systems. No cleartext ever touches the hard drive's platter. Disk Encryption with <application>gbde</application> Configuring gbde requires superuser privileges. &prompt.user; su - Password: If using a custom kernel configuration file, ensure it contains this line: options GEOM_BDE If the kernel already contains this support, use kldload to load &man.gbde.4;: &prompt.root; kldload geom_bde Preparing the Encrypted Hard Drive The following example demonstrates adding a new hard drive to a system that will hold a single encrypted partition. This partition will be mounted as /private. gbde can also be used to encrypt /home and /var/mail, but this requires more complex instructions which exceed the scope of this introduction. Add the New Hard Drive Install the new drive to the system as explained in . For the purposes of this example, a new hard drive partition has been added as /dev/ad4s1c and /dev/ad0s1* represents the existing standard &os; partitions. &prompt.root; ls /dev/ad* /dev/ad0 /dev/ad0s1b /dev/ad0s1e /dev/ad4s1 /dev/ad0s1 /dev/ad0s1c /dev/ad0s1f /dev/ad4s1c /dev/ad0s1a /dev/ad0s1d /dev/ad4 Create a Directory to Hold <command>gbde</command> Lock Files &prompt.root; mkdir /etc/gbde The gbde lock file contains information that gbde requires to access encrypted partitions. Without access to the lock file, gbde will not be able to decrypt the data contained in the encrypted partition without significant manual intervention which is not supported by the software. Each encrypted partition uses a separate lock file. Initialize the <command>gbde</command> Partition A gbde partition must be initialized before it can be used. This initialization needs to be performed only once: &prompt.root; gbde init /dev/ad4s1c -i -L /etc/gbde/ad4s1c.lock &man.gbde.8; will open the default editor, in order to set various configuration options in a template. For use with UFS1 or UFS2, set the sector_size to 2048: # $FreeBSD: src/sbin/gbde/template.txt,v 1.1.36.1 2009/08/03 08:13:06 kensmith Exp $ # # Sector size is the smallest unit of data which can be read or written. # Making it too small decreases performance and decreases available space. # Making it too large may prevent filesystems from working. 512 is the # minimum and always safe. For UFS, use the fragment size # sector_size = 2048 [...] &man.gbde.8; will ask the user twice to type the passphrase used to secure the data. The passphrase must be the same both times. The ability of gbde to protect data depends entirely on the quality of the passphrase. For tips on how to select a secure passphrase that is easy to remember, see the Diceware Passphrase website. gbde initcreates a lock file for the gbde partition. In this example, it is stored as /etc/gbde/ad4s1c.lock. gbde lock files must end in .lock in order to be correctly detected by the /etc/rc.d/gbde start up script. gbde lock files must be backed up together with the contents of any encrypted partitions. While deleting a lock file alone cannot prevent a determined attacker from decrypting a gbde partition, without the lock file, the legitimate owner will be unable to access the data on the encrypted partition without a significant amount of work that is totally unsupported by &man.gbde.8;. Attach the Encrypted Partition to the Kernel &prompt.root; gbde attach /dev/ad4s1c -l /etc/gbde/ad4s1c.lock This command will prompt to input the passphrase that was selected during the initialization of the encrypted partition. The new encrypted device will appear in /dev as /dev/device_name.bde: &prompt.root; ls /dev/ad* /dev/ad0 /dev/ad0s1b /dev/ad0s1e /dev/ad4s1 /dev/ad0s1 /dev/ad0s1c /dev/ad0s1f /dev/ad4s1c /dev/ad0s1a /dev/ad0s1d /dev/ad4 /dev/ad4s1c.bde Create a File System on the Encrypted Device Once the encrypted device has been attached to the kernel, a file system can be created on the device using &man.newfs.8;. This example creates a UFS2 file system with soft updates enabled. &prompt.root; newfs -U /dev/ad4s1c.bde &man.newfs.8; must be performed on an attached gbde partition which is identified by a *.bde extension to the device name. Mount the Encrypted Partition Create a mount point for the encrypted file system: &prompt.root; mkdir /private Mount the encrypted file system: &prompt.root; mount /dev/ad4s1c.bde /private Verify That the Encrypted File System is Available The encrypted file system should now be visible to &man.df.1; and be available for use. &prompt.user; df -H Filesystem Size Used Avail Capacity Mounted on /dev/ad0s1a 1037M 72M 883M 8% / /devfs 1.0K 1.0K 0B 100% /dev /dev/ad0s1f 8.1G 55K 7.5G 0% /home /dev/ad0s1e 1037M 1.1M 953M 0% /tmp /dev/ad0s1d 6.1G 1.9G 3.7G 35% /usr /dev/ad4s1c.bde 150G 4.1K 138G 0% /private Mounting Existing Encrypted File Systems After each boot, any encrypted file systems must be re-attached to the kernel, checked for errors, and mounted, before the file systems can be used. The required commands must be executed as root. Attach the <command>gbde</command> Partition to the Kernel &prompt.root; gbde attach /dev/ad4s1c -l /etc/gbde/ad4s1c.lock This command will prompt for the passphrase that was selected during initialization of the encrypted gbde partition. Check the File System for Errors Since encrypted file systems cannot yet be listed in /etc/fstab for automatic mounting, the file systems must be checked for errors by running &man.fsck.8; manually before mounting: &prompt.root; fsck -p -t ffs /dev/ad4s1c.bde Mount the Encrypted File System &prompt.root; mount /dev/ad4s1c.bde /private The encrypted file system is now available for use. Automatically Mounting Encrypted Partitions It is possible to create a script to automatically attach, check, and mount an encrypted partition, but for security reasons the script should not contain the &man.gbde.8; password. Instead, it is recommended that such scripts be run manually while providing the password via the console or &man.ssh.1;. As an alternative, an rc.d script is provided. Arguments for this script can be passed via &man.rc.conf.5;: gbde_autoattach_all="YES" gbde_devices="ad4s1c" gbde_lockdir="/etc/gbde" This requires that the gbde passphrase be entered at boot time. After typing the correct passphrase, the gbde encrypted partition will be mounted automatically. This can be useful when using gbde on laptops. Cryptographic Protections Employed by <command>gbde</command> &man.gbde.8; encrypts the sector payload using 128-bit AES in CBC mode. Each sector on the disk is encrypted with a different AES key. For more information on the cryptographic design, including how the sector keys are derived from the user-supplied passphrase, refer to &man.gbde.4;. Compatibility Issues &man.sysinstall.8; is incompatible with gbde-encrypted devices. All *.bde devices must be detached from the kernel before starting &man.sysinstall.8; or it will crash during its initial probing for devices. To detach the encrypted device used in the example, use the following command: &prompt.root; gbde detach /dev/ad4s1c Also, since &man.vinum.4; does not use the &man.geom.4; subsystem, gbde can not be used with vinum volumes. Daniel Gerzo Contributed by Disk Encryption with <command>geli</command> An alternative cryptographic GEOM class is available through &man.geli.8;. geli differs from gbde; offers different features, and uses a different scheme for doing cryptographic work. &man.geli.8; provides the following features: Utilizes the &man.crypto.9; framework and, when cryptographic hardware is available, geli uses it automatically. Supports multiple cryptographic algorithms such as AES, Blowfish, and 3DES. Allows the root partition to be encrypted. The passphrase used to access the encrypted root partition will be requested during system boot. Allows the use of two independent keys such as a key and a company key. geli is fast as it performs simple sector-to-sector encryption. Allows backup and restore of master keys. If a user destroys their keys, it is still possible to get access to the data by restoring keys from the backup. Allows a disk to attach with a random, one-time key which is useful for swap partitions and temporary file systems. More geli features can be found in &man.geli.8;. This section describes how to enable support for geli in the &os; kernel and explains how to create and use a geli encryption provider. Superuser privileges are required since modifications to the kernel are necessary. Adding <command>geli</command> Support to the Kernel For a custom kernel, ensure the kernel configuration file contains these lines: options GEOM_ELI device crypto Alternatively, the geli module can be loaded at boot time by adding the following line to /boot/loader.conf: geom_eli_load="YES" &man.geli.8; should now be supported by the kernel. Generating the Master Key The following example describes how to generate a key file which will be used as part of the master key for the encrypted provider mounted under /private. The key file will provide some random data used to encrypt the master key. The master key will also be protected by a passphrase. The provider's sector size will be 4kB. The example will describe how to attach to the geli provider, create a file system on it, mount it, work with it, and finally, how to detach it. It is recommended to use a bigger sector size, such as 4kB, for better performance. The master key will be protected with a passphrase and the data source for the key file will be /dev/random. The sector size of the provider /dev/da2.eli will be 4kB. &prompt.root; dd if=/dev/random of=/root/da2.key bs=64 count=1 &prompt.root; geli init -s 4096 -K /root/da2.key /dev/da2 Enter new passphrase: Reenter new passphrase: It is not mandatory to use both a passphrase and a key file as either method of securing the master key can be used in isolation. If the key file is given as -, standard input will be used. This example shows how more than one key file can be used: &prompt.root; cat keyfile1 keyfile2 keyfile3 | geli init -K - /dev/da2 Attaching the Provider with the Generated Key &prompt.root; geli attach -k /root/da2.key /dev/da2 Enter passphrase: The new plaintext device will be named /dev/da2.eli. &prompt.root; ls /dev/da2* /dev/da2 /dev/da2.eli Creating the New File System &prompt.root; dd if=/dev/random of=/dev/da2.eli bs=1m &prompt.root; newfs /dev/da2.eli &prompt.root; mount /dev/da2.eli /private The encrypted file system should now be visible to &man.df.1; and be available for use: &prompt.root; df -H Filesystem Size Used Avail Capacity Mounted on /dev/ad0s1a 248M 89M 139M 38% / /devfs 1.0K 1.0K 0B 100% /dev /dev/ad0s1f 7.7G 2.3G 4.9G 32% /usr /dev/ad0s1d 989M 1.5M 909M 0% /tmp /dev/ad0s1e 3.9G 1.3G 2.3G 35% /var /dev/da2.eli 150G 4.1K 138G 0% /private Unmounting and Detaching the Provider Once the work on the encrypted partition is done, and the /private partition is no longer needed, it is prudent to consider unmounting and detaching the geli encrypted partition from the kernel: &prompt.root; umount /private &prompt.root; geli detach da2.eli More information about the use of &man.geli.8; can be found in its manual page. Using the <filename>geli</filename> <filename>rc.d</filename> Script geli comes with a rc.d script which can be used to simplify the usage of geli. An example of configuring geli through &man.rc.conf.5; follows: geli_devices="da2" geli_da2_flags="-p -k /root/da2.key" This configures /dev/da2 as a geli provider of which the master key file is located in /root/da2.key. geli will not use a passphrase when attaching to the provider if was given during the geli init phase. The system will detach the geli provider from the kernel before the system shuts down. More information about configuring rc.d is provided in the rc.d section of the Handbook. Christian Brüffer Written by Encrypting Swap Space swap encrypting - Swap encryption in &os; is easy to configure. Depending on - which version of &os; is being used, different options are - available and configuration can vary slightly. The &man.gbde.8; - or &man.geli.8; encryption systems can be used for swap - encryption. Both systems use the encswap + Like the encryption of disk partitions, encryption of swap + space is used to protect sensitive information. Consider an + application that deals with passwords. As long as these + passwords stay in physical memory, these passwords will not + be written to disk and be cleared after a reboot. If &os; + starts swapping out memory pages to free + space for other applications, the passwords may be written to + the disk platters unencrypted. Encrypting swap space can be a + solution for this scenario. + + The &man.gbde.8; or &man.geli.8; encryption systems may be + used for swap encryption. Both systems use the + encswap rc.d script. - - Why Should Swap be Encrypted? - - Like the encryption of disk partitions, encryption of swap - space is used to protect sensitive information. Consider an - application that deals with passwords. As long as these - passwords stay in physical memory, all is well. However, if - the operating system starts swapping out memory pages to free - space for other applications, the passwords may be written to - the disk platters unencrypted. Encrypting swap space can be a - solution for this scenario. - - - - Preparation - - - For the remainder of this section, - ad0s1b will be the swap - partition. - + + For the remainder of this section, + ad0s1b will be the swap + partition. + - By default, swap is unencrypted. It is possible that it - contains passwords or other sensitive data in cleartext. To - rectify this, the data on the swap partition should be - overwritten with random garbage: + Swap partitions are not encrypted by default and should + be cleared of any sensitive data before continuing. To + overwrite the current swap parition with random garbage, + execute the following command: - &prompt.root; dd if=/dev/random of=/dev/ad0s1b bs=1m - + &prompt.root; dd if=/dev/random of=/dev/ad0s1b bs=1m Swap Encryption with &man.gbde.8; The .bde suffix should be added to the device in the respective /etc/fstab swap line: # Device Mountpoint FStype Options Dump Pass# /dev/ad0s1b.bde none swap sw 0 0 Swap Encryption with &man.geli.8; The procedure for instead using &man.geli.8; for swap encryption is similar to that of using &man.gbde.8;. The .eli suffix should be added to the device in the respective /etc/fstab swap line: # Device Mountpoint FStype Options Dump Pass# /dev/ad0s1b.eli none swap sw 0 0 &man.geli.8; uses the AES algorithm with a key length of 128 bit by default. These defaults can be altered by using geli_swap_flags in /etc/rc.conf. The following line tells the encswap rc.d script to create &man.geli.8; swap partitions using the Blowfish algorithm with a key length of 128 bits and a sectorsize of 4 kilobytes, and sets detach on last close: geli_swap_flags="-e blowfish -l 128 -s 4096 -d" Refer to the description of onetime in &man.geli.8; for a list of possible options. - Verifying That it Works + Encrypted Swap Verification Once the system has rebooted, proper operation of the encrypted swap can be verified using swapinfo. If &man.gbde.8; is being used: &prompt.user; swapinfo Device 1K-blocks Used Avail Capacity /dev/ad0s1b.bde 542720 0 542720 0% If &man.geli.8; is being used: &prompt.user; swapinfo Device 1K-blocks Used Avail Capacity /dev/ad0s1b.eli 542720 0 542720 0% Daniel Gerzo Contributed by Freddie Cash With inputs from Pawel Jakub Dawidek Michael W. Lucas Viktor Petersson Highly Available Storage (HAST) HAST high availability Synopsis High availability is one of the main requirements in serious business applications and highly-available storage is a key component in such environments. Highly Available STorage, or HASTHighly Available STorage, was developed by &a.pjd; as a framework which allows transparent storage of the same data across several physically separated machines connected by a TCP/IP network. HAST can be understood as a network-based RAID1 (mirror), and is similar to the DRBD® storage system known from the GNU/&linux; platform. In combination with other high-availability features of &os; like CARP, HAST makes it possible to build a highly-available storage cluster that is resistant to hardware failures. After reading this section, you will know: What HAST is, how it works and which features it provides. How to set up and use HAST on &os;. How to integrate CARP and &man.devd.8; to build a robust storage system. Before reading this section, you should: Understand &unix; and &os; basics. Know how to configure network interfaces and other core &os; subsystems. Have a good understanding of &os; networking. The HAST project was sponsored by The &os; Foundation with support from OMCnet Internet Service GmbH and TransIP BV. HAST Features The main features of the HAST system are: Can be used to mask I/O errors on local hard drives. File system agnostic as it works with any file system supported by &os;. Efficient and quick resynchronization, synchronizing only blocks that were modified during the downtime of a node. Can be used in an already deployed environment to add additional redundancy. Together with CARP, Heartbeat, or other tools, it can be used to build a robust and durable storage system. HAST Operation As HAST provides a synchronous block-level replication of any storage media to several machines, it requires at least two physical machines: the primary, also known as the master node, and the secondary or slave node. These two machines together are referred to as a cluster. HAST is currently limited to two cluster nodes in total. Since HAST works in a primary-secondary configuration, it allows only one of the cluster nodes to be active at any given time. The primary node, also called active, is the one which will handle all the I/O requests to HAST-managed devices. The secondary node is automatically synchronized from the primary node. The physical components of the HAST system are: local disk on primary node, and disk on remote, secondary node. HAST operates synchronously on a block level, making it transparent to file systems and applications. HAST provides regular GEOM providers in /dev/hast/ for use by other tools or applications, thus there is no difference between using HAST-provided devices and raw disks or partitions. Each write, delete, or flush operation is sent to the local disk and to the remote disk over TCP/IP. Each read operation is served from the local disk, unless the local disk is not up-to-date or an I/O error occurs. In such case, the read operation is sent to the secondary node. Synchronization and Replication Modes HAST tries to provide fast failure recovery. For this reason, it is very important to reduce synchronization time after a node's outage. To provide fast synchronization, HAST manages an on-disk bitmap of dirty extents and only synchronizes those during a regular synchronization, with an exception of the initial sync. There are many ways to handle synchronization. HAST implements several replication modes to handle different synchronization methods: memsync: report write operation as completed when the local write operation is finished and when the remote node acknowledges data arrival, but before actually storing the data. The data on the remote node will be stored directly after sending the acknowledgement. This mode is intended to reduce latency, but still provides very good reliability. fullsync: report write operation as completed when local write completes and when remote write completes. This is the safest and the slowest replication mode. This mode is the default. async: report write operation as completed when local write completes. This is the fastest and the most dangerous replication mode. It should be used when replicating to a distant node where latency is too high for other modes. HAST Configuration HAST requires GEOM_GATE support which is not present in the default GENERIC kernel. However, the geom_gate.ko loadable module is available in the default &os; installation. Alternatively, to build GEOM_GATE support into the kernel statically, add this line to the custom kernel configuration file: options GEOM_GATE The HAST framework consists of several parts from the operating system's point of view: the &man.hastd.8; daemon responsible for data synchronization, the &man.hastctl.8; userland management utility, and the &man.hast.conf.5; configuration file. The following example describes how to configure two nodes in master-slave / primary-secondary operation using HAST to replicate the data between the two. The nodes will be called hasta with an IP address of 172.16.0.1 and hastb with an IP of address 172.16.0.2. Both nodes will have a dedicated hard drive /dev/ad6 of the same size for HAST operation. The HAST pool, sometimes also referred to as a resource or the GEOM provider in /dev/hast/, will be called test. Configuration of HAST is done using /etc/hast.conf. This file should be the same on both nodes. The simplest configuration possible is: resource test { on hasta { local /dev/ad6 remote 172.16.0.2 } on hastb { local /dev/ad6 remote 172.16.0.1 } } For more advanced configuration, refer to &man.hast.conf.5;. It is also possible to use host names in the remote statements. In such a case, make sure that these hosts are resolvable and are defined in /etc/hosts or in the local DNS. Now that the configuration exists on both nodes, the HAST pool can be created. Run these commands on both nodes to place the initial metadata onto the local disk and to start &man.hastd.8;: &prompt.root; hastctl create test &prompt.root; service hastd onestart It is not possible to use GEOM providers with an existing file system or to convert an existing storage to a HAST-managed pool. This procedure needs to store some metadata on the provider and there will not be enough required space available on an existing provider. A HAST node's primary or secondary role is selected by an administrator, or software like Heartbeat, using &man.hastctl.8;. On the primary node, hasta, issue this command: &prompt.root; hastctl role primary test Similarly, run this command on the secondary node, hastb: &prompt.root; hastctl role secondary test When the nodes are unable to communicate with each other, and both are configured as primary nodes, the condition is called split-brain. To troubleshoot this situation, follow the steps described in . Verify the result by running &man.hastctl.8; on each node: &prompt.root; hastctl status test The important text is the status line, which should say complete on each of the nodes. If it says degraded, something went wrong. At this point, the synchronization between the nodes has already started. The synchronization completes when hastctl status reports 0 bytes of dirty extents. The next step is to create a filesystem on the /dev/hast/test GEOM provider and mount it. This must be done on the primary node, as /dev/hast/test appears only on the primary node. Creating the filesystem can take a few minutes, depending on the size of the hard drive: &prompt.root; newfs -U /dev/hast/test &prompt.root; mkdir /hast/test &prompt.root; mount /dev/hast/test /hast/test Once the HAST framework is configured properly, the final step is to make sure that HAST is started automatically during system boot. Add this line to /etc/rc.conf: hastd_enable="YES" Failover Configuration The goal of this example is to build a robust storage system which is resistant to the failure of any given node. The scenario is that a primary node of the cluster fails. If this happens, the secondary node is there to take over seamlessly, check and mount the file system, and continue to work without missing a single bit of data. To accomplish this task, another &os; feature, CARP, provides for automatic failover on the IP layer. CARP (Common Address Redundancy Protocol) allows multiple hosts on the same network segment to share an IP address. Set up CARP on both nodes of the cluster according to the documentation available in . After setup, each node will have its own carp0 interface with a shared IP address of 172.16.0.254. The primary HAST node of the cluster must be the master CARP node. The HAST pool created in the previous section is now ready to be exported to the other hosts on the network. This can be accomplished by exporting it through NFS or Samba, using the shared IP address 172.16.0.254. The only problem which remains unresolved is an automatic failover should the primary node fail. In the event of CARP interfaces going up or down, the &os; operating system generates a &man.devd.8; event, making it possible to watch for state changes on the CARP interfaces. A state change on the CARP interface is an indication that one of the nodes failed or came back online. These state change events make it possible to run a script which will automatically handle the HAST failover. To be able to catch state changes on the CARP interfaces, add this configuration to /etc/devd.conf on each node: notify 30 { match "system" "IFNET"; match "subsystem" "carp0"; match "type" "LINK_UP"; action "/usr/local/sbin/carp-hast-switch master"; }; notify 30 { match "system" "IFNET"; match "subsystem" "carp0"; match "type" "LINK_DOWN"; action "/usr/local/sbin/carp-hast-switch slave"; }; Restart &man.devd.8; on both nodes to put the new configuration into effect: &prompt.root; service devd restart When the carp0 interface state changes by going up or down , the system generates a notification, allowing the &man.devd.8; subsystem to run an arbitrary script, in this case /usr/local/sbin/carp-hast-switch. This script handles the automatic failover. For further clarification about the above &man.devd.8; configuration, refer to &man.devd.conf.5;. An example of such a script could be: #!/bin/sh # Original script by Freddie Cash <fjwcash@gmail.com> # Modified by Michael W. Lucas <mwlucas@BlackHelicopters.org> # and Viktor Petersson <vpetersson@wireload.net> # The names of the HAST resources, as listed in /etc/hast.conf resources="test" # delay in mounting HAST resource after becoming master # make your best guess delay=3 # logging log="local0.debug" name="carp-hast" # end of user configurable stuff case "$1" in master) logger -p $log -t $name "Switching to primary provider for ${resources}." sleep ${delay} # Wait for any "hastd secondary" processes to stop for disk in ${resources}; do while $( pgrep -lf "hastd: ${disk} \(secondary\)" > /dev/null 2>&1 ); do sleep 1 done # Switch role for each disk hastctl role primary ${disk} if [ $? -ne 0 ]; then logger -p $log -t $name "Unable to change role to primary for resource ${disk}." exit 1 fi done # Wait for the /dev/hast/* devices to appear for disk in ${resources}; do for I in $( jot 60 ); do [ -c "/dev/hast/${disk}" ] && break sleep 0.5 done if [ ! -c "/dev/hast/${disk}" ]; then logger -p $log -t $name "GEOM provider /dev/hast/${disk} did not appear." exit 1 fi done logger -p $log -t $name "Role for HAST resources ${resources} switched to primary." logger -p $log -t $name "Mounting disks." for disk in ${resources}; do mkdir -p /hast/${disk} fsck -p -y -t ufs /dev/hast/${disk} mount /dev/hast/${disk} /hast/${disk} done ;; slave) logger -p $log -t $name "Switching to secondary provider for ${resources}." # Switch roles for the HAST resources for disk in ${resources}; do if ! mount | grep -q "^/dev/hast/${disk} on " then else umount -f /hast/${disk} fi sleep $delay hastctl role secondary ${disk} 2>&1 if [ $? -ne 0 ]; then logger -p $log -t $name "Unable to switch role to secondary for resource ${disk}." exit 1 fi logger -p $log -t $name "Role switched to secondary for resource ${disk}." done ;; esac In a nutshell, the script takes these actions when a node becomes master / primary: Promotes the HAST pools to primary on a given node. Checks the file system under the HAST pool. Mounts the pools at an appropriate place. When a node becomes backup / secondary: Unmounts the HAST pools. Degrades the HAST pools to secondary. Keep in mind that this is just an example script which serves as a proof of concept. It does not handle all the possible scenarios and can be extended or altered in any way, for example, to start/stop required services. For this example, a standard UFS file system was used. To reduce the time needed for recovery, a journal-enabled UFS or ZFS file system can be used instead. More detailed information with additional examples can be found in the HAST Wiki page. Troubleshooting General Troubleshooting Tips HAST should generally work without issues. However, as with any other software product, there may be times when it does not work as supposed. The sources of the problems may be different, but the rule of thumb is to ensure that the time is synchronized between all nodes of the cluster. When troubleshooting HAST problems, the debugging level of &man.hastd.8; should be increased by starting &man.hastd.8; with -d. This argument may be specified multiple times to further increase the debugging level. A lot of useful information may be obtained this way. Consider also using -F, which starts &man.hastd.8; in the foreground. Recovering from the Split-brain Condition Split-brain is when the nodes of the cluster are unable to communicate with each other, and both are configured as primary. This is a dangerous condition because it allows both nodes to make incompatible changes to the data. This problem must be corrected manually by the system administrator. The administrator must decide which node has more important changes (or merge them manually) and let HAST perform full synchronization of the node which has the broken data. To do this, issue these commands on the node which needs to be resynchronized: &prompt.root; hastctl role init <resource> &prompt.root; hastctl create <resource> &prompt.root; hastctl role secondary <resource> diff --git a/en_US.ISO8859-1/books/handbook/eresources/chapter.xml b/en_US.ISO8859-1/books/handbook/eresources/chapter.xml index af585cf8b8..0ea9b6e6a0 100644 --- a/en_US.ISO8859-1/books/handbook/eresources/chapter.xml +++ b/en_US.ISO8859-1/books/handbook/eresources/chapter.xml @@ -1,2312 +1,2308 @@ Resources on the Internet - The rapid pace of FreeBSD progress makes print media + The rapid pace of &os; progress makes print media impractical as a means of following the latest developments. Electronic resources are the best, if not often the only, way - to stay informed of the latest advances. Since FreeBSD is a + to stay informed of the latest advances. Since &os; is a volunteer effort, the user community itself also generally serves as a technical support department of sorts, with electronic mail, web forums, and USENET news being the most effective way of reaching that community. - The most important points of contact with the FreeBSD user - community are outlined below. If you are aware of other resources - not mentioned here, please send them to the &a.doc; so that they + The most important points of contact with the &os; user + community are outlined below. Please send other resources + not mentioned here to the &a.doc; so that they may also be included. Mailing Lists The mailing lists are the most direct way of addressing questions or opening a technical discussion to a concentrated - FreeBSD audience. There are a wide variety of lists on a number - of different FreeBSD topics. Addressing your questions to the + &os; audience. There are a wide variety of lists on a number + of different &os; topics. Sending questions to the most appropriate mailing list will invariably assure a faster and more accurate response. The charters for the various lists are given at the bottom of this document. Please read the charter before - joining or sending mail to any list. Most of our - list subscribers now receive many hundreds of FreeBSD related - messages every day, and by setting down charters and rules for - proper use we are striving to keep the signal-to-noise ratio + joining or sending mail to any list. Most + list subscribers receive many hundreds of &os; related + messages every day, and the charters and rules for + use are meant to keep the signal-to-noise ratio of the lists high. To do less would see the mailing lists ultimately fail as an effective communications medium for the - project. + Project. - If you wish to test your ability to send to + To test the ability to send email to &os; lists, send a test message to &a.test.name;. Please do not send test messages to any other list. When in doubt about what list to post a question to, see How to get best results from the FreeBSD-questions mailing list. Before posting to any list, please learn about how to best use the mailing lists, such as how to help avoid frequently-repeated discussions, by reading the Mailing List Frequently Asked Questions (FAQ) document. Archives are kept for all of the mailing lists and can be searched using the FreeBSD World Wide Web + url="&url.base;/search/index.html">&os; World Wide Web server. The keyword searchable archive offers an excellent way of finding answers to frequently asked questions and should be consulted before posting a question. Note that - this also means that messages sent to FreeBSD mailing lists + this also means that messages sent to &os; mailing lists are archived in perpetuity. When protecting privacy is a concern, consider using a disposable secondary email address and posting only public information. List Summary General lists: The following are general lists which anyone is free (and encouraged) to join: List Purpose &a.advocacy.name; - FreeBSD Evangelism + &os; Evangelism &a.announce.name; - Important events and project milestones (moderated) + Important events and Project milestones +(moderated) &a.arch.name; Architecture and design discussions &a.bugbusters.name; Discussions pertaining to the maintenance of - the FreeBSD problem report database and related + the &os; problem report database and related tools &a.bugs.name; Bug reports &a.chat.name; - Non-technical items related to the FreeBSD + Non-technical items related to the &os; community &a.chromium.name; - FreeBSD-specific Chromium issues + &os;-specific Chromium issues &a.current.name; Discussion concerning the use of &os.current; &a.isp.name; Issues for Internet Service Providers using - FreeBSD + &os; &a.jobs.name; - FreeBSD employment and consulting + &os; employment and consulting opportunities &a.questions.name; User questions and technical support &a.security-notifications.name; Security notifications (moderated) &a.stable.name; Discussion concerning the use of &os.stable; &a.test.name; - Where to send your test messages instead of + Where to send test messages instead of to one of the actual lists Technical lists: The following - lists are for technical discussion. You should read the + lists are for technical discussion. Read the charter for each list carefully before joining or sending mail to one as there are firm guidelines for their use and content. List Purpose &a.acpi.name; ACPI and power management development &a.afs.name; - Porting AFS to FreeBSD + Porting AFS to &os; &a.aic7xxx.name; Developing drivers for the &adaptec; AIC 7xxx &a.amd64.name; - Porting FreeBSD to AMD64 systems (moderated) + Porting &os; to AMD64 systems (moderated) &a.apache.name; Discussion about Apache related ports &a.arm.name; - Porting FreeBSD to &arm; processors + Porting &os; to &arm; processors &a.atm.name; - Using ATM networking with FreeBSD + Using ATM networking with &os; &a.bluetooth.name; - Using &bluetooth; technology in FreeBSD + Using &bluetooth; technology in &os; &a.cluster.name; - Using FreeBSD in a clustered environment + Using &os; in a clustered environment &a.cvsweb.name; CVSweb maintenance &a.database.name; Discussing database use and development under - FreeBSD + &os; &a.desktop.name; Using and improving &os; on the desktop &a.doc.name; - Creating FreeBSD related documents + Creating &os; related documents &a.drivers.name; Writing device drivers for &os; &a.dtrace.name; Using and working on DTrace in &os; &a.eclipse.name; - FreeBSD users of Eclipse IDE, tools, rich client + &os; users of Eclipse IDE, tools, rich client applications and ports. &a.embedded.name; - Using FreeBSD in embedded applications + Using &os; in embedded applications &a.eol.name; - Peer support of FreeBSD-related software that - is no longer supported by the FreeBSD project. + Peer support of &os;-related software that + is no longer supported by the &os; Project. &a.emulation.name; Emulation of other systems such as Linux/&ms-dos;/&windows; &a.firewire.name; - FreeBSD &firewire; (iLink, IEEE 1394) technical + &os; &firewire; (iLink, IEEE 1394) technical discussion &a.fs.name; File systems &a.gecko.name; Gecko Rendering Engine issues &a.geom.name; GEOM-specific discussions and implementations &a.gnome.name; Porting GNOME and GNOME applications &a.hackers.name; General technical discussion &a.hardware.name; General discussion of hardware for running - FreeBSD + &os; &a.i18n.name; - FreeBSD Internationalization + &os; Internationalization &a.ia32.name; - FreeBSD on the IA-32 (&intel; x86) + &os; on the IA-32 (&intel; x86) platform &a.ia64.name; - Porting FreeBSD to &intel;'s upcoming IA64 + Porting &os; to &intel;'s upcoming IA64 systems &a.infiniband.name; - Infiniband on FreeBSD + Infiniband on &os; &a.ipfw.name; Technical discussion concerning the redesign of the IP firewall code &a.isdn.name; ISDN developers &a.jail.name; Discussion about the &man.jail.8; facility &a.java.name; &java; developers and people porting &jdk;s to - FreeBSD - - - - &a.kde.name; - Porting KDE and - KDE applications + &os; &a.lfs.name; - Porting LFS to FreeBSD + Porting LFS to &os; &a.mips.name; - Porting FreeBSD to &mips; + Porting &os; to &mips; &a.mobile.name; Discussions about mobile computing &a.mono.name; - Mono and C# applications on FreeBSD + Mono and C# applications on &os; &a.mozilla.name; Porting Mozilla to - FreeBSD + &os; &a.multimedia.name; Multimedia applications &a.newbus.name; Technical discussions about bus architecture &a.net.name; Networking discussion and TCP/IP source code &a.numerics.name; Discussions of high quality implementation of libm functions &a.office.name; Office applications on &os; &a.performance.name; Performance tuning questions for high performance/load installations &a.perl.name; Maintenance of a number of Perl-related ports &a.pf.name; Discussion and questions about the packet filter firewall system &a.platforms.name; Concerning ports to non &intel; architecture platforms &a.ports.name; Discussion of the Ports Collection &a.ports-announce.name; Important news and instructions about the Ports Collection (moderated) &a.ports-bugs.name; Discussion of the ports bugs/PRs &a.ppc.name; - Porting FreeBSD to the &powerpc; + Porting &os; to the &powerpc; &a.proliant.name; - Technical discussion of FreeBSD on HP ProLiant + Technical discussion of &os; on HP ProLiant server platforms &a.python.name; - FreeBSD-specific Python issues + &os;-specific Python issues &a.rc.name; Discussion related to the rc.d system and its development &a.realtime.name; Development of realtime extensions to - FreeBSD + &os; &a.ruby.name; - FreeBSD-specific Ruby discussions + &os;-specific Ruby discussions &a.scsi.name; The SCSI subsystem &a.security.name; - Security issues affecting FreeBSD + Security issues affecting &os; &a.small.name; - Using FreeBSD in embedded applications + Using &os; in embedded applications (obsolete; use &a.embedded.name; instead) &a.snapshots.name; &os; Development Snapshot Announcements &a.sparc.name; - Porting FreeBSD to &sparc; based systems + Porting &os; to &sparc; based systems &a.standards.name; - FreeBSD's conformance to the C99 and the &posix; + &os;'s conformance to the C99 and the &posix; standards &a.sysinstall.name; &man.sysinstall.8; development &a.tcltk.name; - FreeBSD-specific Tcl/Tk discussions + &os;-specific Tcl/Tk discussions &a.testing.name; Testing on &os; &a.tex.name; Porting TeX and its applications to &os; &a.threads.name; - Threading in FreeBSD + Threading in &os; &a.tilera.name; - Porting FreeBSD to the Tilera family of + Porting &os; to the Tilera family of CPUs &a.tokenring.name; - Support Token Ring in FreeBSD + Support Token Ring in &os; &a.toolchain.name; Maintenance of &os;'s integrated toolchain &a.usb.name; Discussing &os; support for USB &a.virtualization.name; Discussion of various virtualization techniques supported by &os; &a.vuxml.name; Discussion on VuXML infrastructure &a.x11.name; - Maintenance and support of X11 on FreeBSD + Maintenance and support of X11 on &os; &a.xen.name; Discussion of the &os; port to &xen; — implementation and usage &a.xfce.name; XFCE for &os; — porting and maintaining &a.zope.name; Zope for &os; — porting and maintaining Limited lists: The following lists are for more specialized (and demanding) audiences and are probably not of interest to the general public. It is also a good idea to establish a presence in the technical lists - before joining one of these limited lists so that you will + before joining one of these limited lists in order to understand the communications etiquette involved. List Purpose &a.hubs.name; People running mirror sites (infrastructural support) &a.usergroups.name; User group coordination &a.wip-status.name; - FreeBSD Work-In-Progress Status + &os; Work-In-Progress Status &a.wireless.name; Discussions of 802.11 stack, tools, device driver development Digest lists: All of the above lists are available in a digest format. Once subscribed to a list, - you can change your digest options in your account options + the digest options can be changed in the account options section. SVN lists: The following lists are for people interested in seeing the log messages for changes to various areas of the source tree. They are Read-Only lists and should not have mail sent to them. List Source area Area Description (source for) &a.svn-doc-all.name; /usr/doc All changes to the doc Subversion repository (except for user, projects and translations) &a.svn-doc-head.name; /usr/doc All changes to the head branch of the doc Subversion repository &a.svn-doc-projects.name; /usr/doc/projects All changes to the projects area of the doc Subversion repository &a.svn-doc-svnadmin.name; /usr/doc All changes to the administrative scripts, hooks, and other configuration data of the doc Subversion repository &a.svn-ports-all.name; /usr/ports All changes to the ports Subversion repository &a.svn-ports-head.name; /usr/ports All changes to the head branch of the ports Subversion repository &a.svn-ports-svnadmin.name; /usr/ports All changes to the administrative scripts, hooks, and other configuration data of the ports Subversion repository &a.svn-src-all.name; /usr/src All changes to the src Subversion repository (except for user and projects) &a.svn-src-head.name; /usr/src All changes to the head branch of the src Subversion repository (the &os;-CURRENT branch) &a.svn-src-projects.name; /usr/projects All changes to the projects area of the src Subversion repository &a.svn-src-release.name; /usr/src All changes to the releases area of the src Subversion repository &a.svn-src-releng.name; /usr/src All changes to the releng branches of the src Subversion repository (the security / release engineering branches) &a.svn-src-stable.name; /usr/src All changes to the all stable branches of the src Subversion repository &a.svn-src-stable-6.name; /usr/src All changes to the stable/6 branch of the src Subversion repository &a.svn-src-stable-7.name; /usr/src All changes to the stable/7 branch of the src Subversion repository &a.svn-src-stable-8.name; /usr/src All changes to the stable/8 branch of the src Subversion repository &a.svn-src-stable-9.name; /usr/src All changes to the stable/9 branch of the src Subversion repository &a.svn-src-stable-other.name; /usr/src All changes to the older stable branches of the src Subversion repository &a.svn-src-svnadmin.name; /usr/src All changes to the administrative scripts, hooks, and other configuration data of the src Subversion repository &a.svn-src-user.name; /usr/src All changes to the experimental user area of the src Subversion repository &a.svn-src-vendor.name; /usr/src All changes to the vendor work area of the src Subversion repository How to Subscribe - To subscribe to a list, click on the list name above or - go to &a.mailman.lists.link; and click on the list that you - are interested in. The list page should contain all of the - necessary subscription instructions. + To subscribe to a list, click the list name at + &a.mailman.lists.link;. + The page that is displayed should contain all of the + necessary subscription instructions for that list. To actually post to a given list, send mail to listname@FreeBSD.org. It will then be redistributed to mailing list members world-wide. - To unsubscribe yourself from a list, click on the URL + To unsubscribe from a list, click on the URL found at the bottom of every email received from the list. It is also possible to send an email to listname-unsubscribe@FreeBSD.org - to unsubscribe yourself. + to unsubscribe. - Again, we would like to request that you keep discussion - in the technical mailing lists on a technical track. If you - are only interested in important announcements then it is - suggested that you join the &a.announce;, which is intended - only for infrequent traffic. + It is important to keep discussion + in the technical mailing lists on a technical track. To + only receive important announcements, instead + join the &a.announce;, which is intended + for infrequent traffic. List Charters - All FreeBSD mailing lists have + All &os; mailing lists have certain basic rules which must be adhered to by anyone using them. Failure to comply with these guidelines will result - in two (2) written warnings from the FreeBSD Postmaster + in two (2) written warnings from the &os; Postmaster postmaster@FreeBSD.org, after which, on a - third offense, the poster will removed from all FreeBSD + third offense, the poster will removed from all &os; mailing lists and filtered from further posting to them. We regret that such rules and measures are necessary at all, but today's Internet is a pretty harsh environment, it would seem, and many fail to appreciate just how fragile some of its mechanisms are. Rules of the road: The topic of any posting should adhere to the basic - charter of the list it is posted to, e.g., if the list - is about technical issues then your posting should contain + charter of the list it is posted to. If the list + is about technical issues, the posting should contain technical discussion. Ongoing irrelevant chatter or flaming only detracts from the value of the mailing list for everyone on it and will not be tolerated. For free-form discussion on no particular topic, the &a.chat; is freely available and should be used instead. No posting should be made to more than 2 mailing lists, and only to 2 when a clear and obvious need to post to both lists exists. For most lists, there is already a great deal of subscriber overlap and except for the most esoteric mixes (say -stable & -scsi), there really is no reason to post to more than one list at - a time. If a message is sent to you in such a way that - multiple mailing lists appear on the Cc - line then the Cc line should also be - trimmed before sending it out again. You are - still responsible for your own cross-postings, no matter + a time. If a message is received with + multiple mailing lists on the Cc + line, trim the Cc line + before replying. The person who replies is + still responsible for cross-posting, no matter who the originator might have been. Personal attacks and profanity (in the context of an argument) are not allowed, and that includes users and developers alike. Gross breaches of netiquette, like excerpting or reposting private mail when permission to do so was not and would not be forthcoming, are frowned upon but not specifically enforced. However, there are also very few cases where such content would fit within the charter of a list and it would therefore probably rate a warning (or ban) on that basis alone. - Advertising of non-FreeBSD related products or + Advertising of non-&os; related products or services is strictly prohibited and will result in an immediate ban if it is clear that the offender is advertising by spam. Individual list charters: &a.acpi.name; ACPI and power management development &a.afs.name; Andrew File System This list is for discussion on porting and using AFS from CMU/Transarc &a.announce.name; Important events / milestones This is the mailing list for people interested - only in occasional announcements of significant FreeBSD + only in occasional announcements of significant &os; events. This includes announcements about snapshots and other releases. It contains announcements of new - FreeBSD capabilities. It may contain calls for + &os; capabilities. It may contain calls for volunteers etc. This is a low volume, strictly moderated mailing list. &a.arch.name; Architecture and design discussions - This list is for discussion of the FreeBSD + This list is for discussion of the &os; architecture. Messages will mostly be kept strictly technical in nature. Examples of suitable topics are: How to re-vamp the build system to have several customized builds running at the same time. What needs to be fixed with VFS to make Heidemann layers work. How do we change the device driver interface to be able to use the same drivers cleanly on many buses and architectures. How to write a network driver. &a.bluetooth.name; - &bluetooth; in FreeBSD + &bluetooth; in &os; - This is the forum where FreeBSD's &bluetooth; users + This is the forum where &os;'s &bluetooth; users congregate. Design issues, implementation details, patches, bug reports, status reports, feature requests, and all matters related to &bluetooth; are fair game. &a.bugbusters.name; Coordination of the Problem Report handling effort The purpose of this list is to serve as a coordination and discussion forum for the Bugmeister, his Bugbusters, and any other parties who have a genuine interest in the PR database. This list is not for discussions about specific bugs, patches or PRs. &a.bugs.name; Bug reports This is the mailing list for reporting bugs in - FreeBSD. Whenever possible, bugs should be submitted + &os;. Whenever possible, bugs should be submitted using the &man.send-pr.1; command or the WEB interface to it. &a.chat.name; - Non technical items related to the FreeBSD + Non technical items related to the &os; community This list contains the overflow from the other lists about non-technical, social information. It includes discussion about whether Jordan looks like a toon ferret or not, whether or not to type in capitals, who is drinking too much coffee, where the best beer is brewed, who is brewing beer in their basement, and so on. Occasional announcements of important events (such as upcoming parties, weddings, births, new jobs, etc) can be made to the technical lists, but the follow ups should be directed to this -chat list. &a.chromium.name; - FreeBSD-specific Chromium + &os;-specific Chromium issues This is a list for the discussion of Chromium - support for FreeBSD. This is a technical list to + support for &os;. This is a technical list to discuss development and installation of Chromium. &a.core.name; - FreeBSD core team + &os; core team This is an internal mailing list for use by the core members. Messages can be sent to it when a serious - FreeBSD-related matter requires arbitration or + &os;-related matter requires arbitration or high-level scrutiny. &a.current.name; Discussions about the use of &os.current; This is the mailing list for users of &os.current;. It includes warnings about new features coming out in -CURRENT that will affect the users, and instructions on steps that must be taken to remain -CURRENT. Anyone running CURRENT must subscribe to this list. This is a technical mailing list for which strictly technical content is expected. &a.cvsweb.name; - FreeBSD CVSweb Project + &os; CVSweb Project Technical discussions about use, development and - maintenance of FreeBSD-CVSweb. + maintenance of &os;-CVSweb. &a.desktop.name; Using and improving &os; on the desktop This is a forum for discussion of &os; on the desktop. It is primarily a place for desktop porters and users to discuss issues and improve &os;'s desktop support. &a.doc.name; - Documentation project + Documentation Project This mailing list is for the discussion of issues and projects related to the creation of documentation - for FreeBSD. The members of this mailing list are - collectively referred to as The FreeBSD + for &os;. The members of this mailing list are + collectively referred to as The &os; Documentation Project. It is an open list; feel free to join and contribute! &a.drivers.name; Writing device drivers for &os; This is a forum for technical discussions related to device drivers on &os;. It is primarily a place for device driver writers to ask questions about how to write device drivers using the APIs in the &os; kernel. &a.dtrace.name; Using and working on DTrace in &os; DTrace is an integrated component of &os; that provides a framework for understanding the kernel as well as user space programs at run time. The mailing list is an archived discussion for developers of the code as well as those using it. &a.eclipse.name; &os; users of Eclipse IDE, tools, rich client applications and ports. The intention of this list is to provide mutual support for everything to do with choosing, installing, using, developing and maintaining the Eclipse IDE, tools, rich client applications on the &os; platform and assisting with the porting of Eclipse IDE and plugins to the &os; environment. The intention is also to facilitate exchange of information between the Eclipse community and the &os; community to the mutual benefit of both. Although this list is focused primarily on the needs of Eclipse users it will also provide a forum for those who would like to develop &os; specific applications using the Eclipse framework. &a.embedded.name; - Using FreeBSD in embedded + Using &os; in embedded applications - This list discusses topics related to using FreeBSD + This list discusses topics related to using &os; in embedded systems. This is a technical mailing list for which strictly technical content is expected. For - the purpose of this list we define embedded systems as + the purpose of this list, embedded systems are those computing devices which are not desktops and which usually serve a single purpose as opposed to being general computing environments. Examples include, but are not limited to, all kinds of phone handsets, network equipment such as routers, switches and PBXs, remote measuring equipment, PDAs, Point Of Sale systems, and so on. &a.emulation.name; Emulation of other systems such as Linux/&ms-dos;/&windows; This is a forum for technical discussions related to running programs written for other operating systems on &os;. &a.eol.name; - Peer support of FreeBSD-related software - that is no longer supported by the FreeBSD - project. + Peer support of &os;-related software + that is no longer supported by the &os; + Project. This list is for those interested in providing or - making use of peer support of FreeBSD-related software - for which the FreeBSD project no longer provides - official support (e.g., in the form of security - advisories and patches). + making use of peer support of &os;-related software + for which the &os; Project no longer provides + official support in the form of security + advisories and patches. &a.firewire.name; &firewire; (iLink, IEEE 1394) This is a mailing list for discussion of the design and implementation of a &firewire; (aka IEEE 1394 aka - iLink) subsystem for FreeBSD. Relevant topics + iLink) subsystem for &os;. Relevant topics specifically include the standards, bus devices and their protocols, adapter boards/cards/chips sets, and the architecture and implementation of code for their proper support. &a.fs.name; File systems - Discussions concerning FreeBSD file systems. + Discussions concerning &os; filesystems. This is a technical mailing list for which strictly technical content is expected. &a.gecko.name; Gecko Rendering Engine This is a forum about Gecko applications using &os;. Discussion centers around Gecko Ports applications, their installation, their development and their support within &os;. &a.geom.name; GEOM Discussions specific to GEOM and related implementations. This is a technical mailing list for which strictly technical content is expected. &a.gnome.name; GNOME Discussions concerning The GNOME Desktop Environment - for FreeBSD systems. This is a technical mailing list + for &os; systems. This is a technical mailing list for which strictly technical content is expected. &a.infiniband.name; Infiniband on &os; Technical mailing list discussing Infiniband, OFED, and OpenSM on &os;. &a.ipfw.name; IP Firewall This is the forum for technical discussions concerning the redesign of the IP firewall code in - FreeBSD. This is a technical mailing list for which + &os;. This is a technical mailing list for which strictly technical content is expected. &a.ia64.name; - Porting FreeBSD to IA64 + Porting &os; to IA64 This is a technical mailing list for individuals - actively working on porting FreeBSD to the IA-64 + actively working on porting &os; to the IA-64 platform from &intel;, to bring up problems or discuss alternative solutions. Individuals interested in following the technical discussion are also welcome. &a.isdn.name; ISDN Communications This is the mailing list for people discussing the - development of ISDN support for FreeBSD. + development of ISDN support for &os;. &a.java.name; &java; Development This is the mailing list for people discussing the development of significant &java; applications for - FreeBSD and the porting and maintenance of + &os; and the porting and maintenance of &jdk;s. &a.jobs.name; Jobs offered and sought This is a forum for posting employment notices - and resumes specifically related to &os;, e.g., if you - are seeking &os;-related employment or have a job - involving &os; to advertise then this is the right - place. This is not a mailing list + specifically related to &os; and resumes from those + seeking &os;-related employment. This is + not a mailing list for general employment issues since adequate forums for that already exist elsewhere. Note that this list, like other FreeBSD.org mailing lists, - is distributed worldwide. Thus, you need to be clear - about location and the extent to which telecommuting or + is distributed worldwide. Be clear + about the geographic location and the extent to which + telecommuting or assistance with relocation is available. Email should use open formats only — preferably plain text, but basic Portable Document Format (PDF), HTML, and a few others are acceptable to many readers. Closed formats such as µsoft; Word (.doc) will be rejected by the mailing list server. &a.kde.name; KDE Discussions concerning - KDE on FreeBSD systems. + KDE on &os; systems. This is a technical mailing list for which strictly technical content is expected. &a.hackers.name; Technical discussions This is a forum for technical discussions related - to FreeBSD. This is the primary technical mailing list. - It is for individuals actively working on FreeBSD, to + to &os;. This is the primary technical mailing list. + It is for individuals actively working on &os;, to bring up problems or discuss alternative solutions. Individuals interested in following the technical discussion are also welcome. This is a technical mailing list for which strictly technical content is expected. &a.hardware.name; - General discussion of FreeBSD + General discussion of &os; hardware General discussion about the types of hardware - that FreeBSD runs on, various problems and suggestions + that &os; runs on, various problems and suggestions concerning what to buy or avoid. &a.hubs.name; Mirror sites Announcements and discussion for people who run - FreeBSD mirror sites. + &os; mirror sites. &a.isp.name; Issues for Internet Service Providers This mailing list is for discussing topics relevant - to Internet Service Providers (ISPs) using FreeBSD. + to Internet Service Providers (ISPs) using &os;. This is a technical mailing list for which strictly technical content is expected. &a.mono.name; Mono and C# applications on - FreeBSD + &os; This is a list for discussions related to the Mono development framework on &os;. This is a technical mailing list. It is for individuals actively working on porting Mono or C# applications to &os;, to bring up problems or discuss alternative solutions. Individuals interested in following the technical discussion are also welcome. &a.office.name; Office applications on &os; Discussion centers around office applications, their installation, their development and their support within &os;. &a.ops-announce.name; Project Infrastructure Announcements This is the mailing list for people interested in - changes and issues related to the FreeBSD.org project + changes and issues related to the FreeBSD.org Project infrastructure. This moderated list is strictly for announcements: no replies, requests, discussions, or opinions. &a.performance.name; - Discussions about tuning or speedingup - FreeBSD + Discussions about tuning or speeding up + &os; This mailing list exists to provide a place for hackers, administrators, and/or concerned parties to discuss performance related topics pertaining to - FreeBSD. Acceptable topics includes talking about - FreeBSD installations that are either under high load, + &os;. Acceptable topics includes talking about + &os; installations that are either under high load, are experiencing performance problems, or are pushing - the limits of FreeBSD. Concerned parties that are + the limits of &os;. Concerned parties that are willing to work toward improving the performance of - FreeBSD are highly encouraged to subscribe to this list. + &os; are highly encouraged to subscribe to this list. This is a highly technical list ideally suited for - experienced FreeBSD users, hackers, or administrators - interested in keeping FreeBSD fast, robust, and + experienced &os; users, hackers, or administrators + interested in keeping &os; fast, robust, and scalable. This list is not a question-and-answer list that replaces reading through documentation, but it is a place to make contributions or inquire about unanswered performance related topics. &a.pf.name; Discussion and questions about the packet filter firewall system Discussion concerning the packet filter (pf) - firewall system in terms of FreeBSD. Technical + firewall system in terms of &os;. Technical discussion and user questions are both welcome. This list is also a place to discuss the ALTQ QoS framework. &a.pkg.name; Binary package management and package tools discussion Discussion of all aspects of managing &os; systems by using binary packages to install software, including binary package toolkits and formats, their development and support within &os;, package repository management, and 3rd party packages. Note that discussion of ports which fail to generate packages correctly should generally be considered as ports problems, and so inappropriate for this list. &a.platforms.name; Porting to Non &intel; platforms - Cross-platform FreeBSD issues, general discussion - and proposals for non &intel; FreeBSD ports. This is + Cross-platform &os; issues, general discussion + and proposals for non &intel; &os; ports. This is a technical mailing list for which strictly technical content is expected. &a.ports.name; Discussion of ports - Discussions concerning FreeBSD's ports + Discussions concerning &os;'s ports collection (/usr/ports), ports infrastructure, and general ports coordination efforts. This is a technical mailing list for which strictly technical content is expected. &a.ports-announce.name; Important news and instructions about the &os; Ports Collection Important news for developers, porters, and users of the Ports Collection (/usr/ports), including architecture/infrastructure changes, new capabilities, critical upgrade instructions, and release engineering information. This is a low-volume mailing list, intended for announcements. &a.ports-bugs.name; Discussion of ports bugs - Discussions concerning problem reports for FreeBSD's + Discussions concerning problem reports for &os;'s ports collection (/usr/ports), proposed ports, or modifications to ports. This is a technical mailing list for which strictly technical content is expected. &a.proliant.name; - Technical discussion of FreeBSD on HP + Technical discussion of &os; on HP ProLiant server platforms This mailing list is to be used for the technical - discussion of the usage of FreeBSD on HP ProLiant + discussion of the usage of &os; on HP ProLiant servers, including the discussion of ProLiant-specific drivers, management software, configuration tools, and BIOS updates. As such, this is the primary place to discuss the hpasmd, hpasmcli, and hpacucli modules. &a.python.name; - Python on FreeBSD + Python on &os; This is a list for discussions related to improving - Python-support on FreeBSD. This is a technical mailing + Python-support on &os;. This is a technical mailing list. It is for individuals working on porting Python, its 3rd party modules and - Zope stuff to FreeBSD. + Zope stuff to &os;. Individuals interested in following the technical discussion are also welcome. &a.questions.name; User questions This is the mailing list for questions about - FreeBSD. You should not send how to - questions to the technical lists unless you consider - the question to be pretty technical. + &os;. Do not send how to + questions to the technical lists unless + the question is quite technical. &a.ruby.name; - FreeBSD-specific Ruby + &os;-specific Ruby discussions This is a list for discussions related to the Ruby - support on FreeBSD. This is a technical mailing + support on &os;. This is a technical mailing list. It is for individuals working on Ruby ports, 3rd party libraries and frameworks. Individuals interested in the technical discussion are also welcome. &a.scsi.name; SCSI subsystem This is the mailing list for people working on - the SCSI subsystem for FreeBSD. This is a technical + the SCSI subsystem for &os;. This is a technical mailing list for which strictly technical content is expected. &a.security.name; Security issues - FreeBSD computer security issues (DES, Kerberos, + &os; computer security issues (DES, Kerberos, known security holes and fixes, etc). This is a technical mailing list for which strictly technical discussion is expected. Note that this is not a question-and-answer list, but that contributions (BOTH question AND answer) to the FAQ are welcome. &a.security-notifications.name; Security Notifications - Notifications of FreeBSD security problems and + Notifications of &os; security problems and fixes. This is not a discussion list. The discussion list is FreeBSD-security. &a.small.name; - Using FreeBSD in embedded + Using &os; in embedded applications This list discusses topics related to unusually - small and embedded FreeBSD installations. This is a + small and embedded &os; installations. This is a technical mailing list for which strictly technical content is expected. This list has been obsoleted by &a.embedded.name;. &a.snapshots.name; &os; Development Snapshot Announcements - This list will notify you about the availability + This list provides notifications about the + availability of new &os; development snapshots for the head/ and stable/ branches. &a.stable.name; Discussions about the use of &os.stable; This is the mailing list for users of &os.stable;. It includes warnings about new features coming out in -STABLE that will affect the users, and instructions on steps that must be taken to remain -STABLE. Anyone running STABLE should subscribe to this list. This is a technical mailing list for which strictly technical content is expected. &a.standards.name; C99 & POSIX Conformance This is a forum for technical discussions related - to FreeBSD Conformance to the C99 and the POSIX + to &os; Conformance to the C99 and the POSIX standards. &a.testing.name; Testing on &os; Technical mailing list discussing testing on &os;, including ATF/Kyua, test build infrastructure, port tests to &os; from other operating systems (NetBSD, ...), etc. &a.tex.name; Porting TeX and its applications to &os; This is a technical mailing list for discussions related to TeX and its applications on &os;. It is for individuals actively working on porting TeX to FreeBSD, to bring up problems or discuss alternative solutions. Individuals interested in following the technical discussion are also welcome. &a.toolchain.name; - Maintenance of FreeBSD's integrated + Maintenance of &os;'s integrated toolchain This is the mailing list for discussions related to the maintenance of the toolchain shipped with &os;. This could include the state of Clang and GCC, but also pieces of software such as assemblers, linkers and debuggers. &a.usb.name; Discussing &os; support for USB This is a mailing list for technical discussions related to &os; support for USB. &a.usergroups.name; User Group Coordination List This is the mailing list for the coordinators from each of the local area Users Groups to discuss matters with each other and a designated individual from the Core Team. This mail list should be limited to meeting synopsis and coordination of projects that span User Groups. &a.virtualization.name; Discussion of various virtualization techniques supported by &os; A list to discuss the various virtualization techniques supported by &os;. On one hand the focus will be on the implementation of the basic functionality as well as adding new features. On the other hand users will have a forum to ask for help in case of problems or to discuss their use cases. &a.wip-status.name; &os; Work-In-Progress Status - This mailing list can be used to announce creation - and progress of your &os; related work. Messages + This mailing list can be used by developers to + announce the creation + and progress of &os; related work. Messages will be moderated. It is suggested to send the message "To:" a more topical &os; list and only "BCC:" - this list. This way your WIP can also be discussed on + this list. This way the WIP can also be discussed on the topical list, as no discussion is allowed on this list. Look inside the archives for examples of suitable messages. An editorial digest of the messages to this list - might be posted to the &os; website every few month + might be posted to the &os; website every few months as part of the Status Reports . - You can find more examples and past reports there, - too. + Past reports are archived. &a.wireless.name; Discussions of 802.11 stack, tools device driver development The FreeBSD-wireless list focuses on 802.11 stack (sys/net80211), device driver and tools development. This includes bugs, new features and maintenance. &a.xen.name; Discussion of the &os; port to &xen; — implementation and usage A list that focuses on the &os; &xen; port. The anticipated traffic level is small enough that it is intended as a forum for both technical discussions of the implementation and design details as well as administrative deployment issues. &a.xfce.name; XFCE This is a forum for discussions related to bring the XFCE environment to &os;. This is a technical mailing list. It is for individuals actively working on porting XFCE to &os;, to bring up problems or discuss alternative solutions. Individuals interested in following the technical discussion are also welcome. &a.zope.name; Zope This is a forum for discussions related to bring the Zope environment to &os;. This is a technical mailing list. It is for individuals actively working on porting Zope to &os;, to bring up problems or discuss alternative solutions. Individuals interested in following the technical discussion are also welcome. Filtering on the Mailing Lists The &os; mailing lists are filtered in multiple ways to avoid the distribution of spam, viruses, and other unwanted emails. The filtering actions described in this section do not include all those used to protect the mailing lists. Only certain types of attachments are allowed on the mailing lists. All attachments with a MIME content type not found in the list below will be stripped before an email is distributed on the mailing lists. application/octet-stream application/pdf application/pgp-signature application/x-pkcs7-signature message/rfc822 multipart/alternative multipart/related multipart/signed text/html text/plain text/x-diff text/x-patch Some of the mailing lists might allow attachments of other MIME content types, but the above list should be applicable for most of the mailing lists. If an email contains both an HTML and a plain text version, the HTML version will be removed. If an email contains only an HTML version, it will be converted to plain text. Usenet Newsgroups - In addition to two FreeBSD specific newsgroups, there are - many others in which FreeBSD is discussed or are otherwise - relevant to FreeBSD users. + In addition to two &os; specific newsgroups, there are + many others in which &os; is discussed or are otherwise + relevant to &os; users. BSD Specific Newsgroups comp.unix.bsd.freebsd.announce comp.unix.bsd.freebsd.misc de.comp.os.unix.bsd (German) fr.comp.os.bsd (French) it.comp.os.freebsd (Italian) Other &unix; Newsgroups of Interest comp.unix comp.unix.questions comp.unix.admin comp.unix.programmer comp.unix.shell comp.unix.user-friendly comp.security.unix comp.sources.unix comp.unix.advocacy comp.unix.misc comp.unix.bsd X Window System comp.windows.x.i386unix comp.windows.x comp.windows.x.apps comp.windows.x.announce comp.windows.x.intrinsics comp.windows.x.motif comp.windows.x.pex comp.emulators.ms-windows.wine World Wide Web Servers Forums, Blogs, and Social Networks The - FreeBSD Forums provide a web based discussion - forum for FreeBSD questions and technical + &os; Forums provide a web based discussion + forum for &os; questions and technical discussion. Planet FreeBSD + url="http://planet.freebsdish.org/">Planet &os; offers an aggregation feed of dozens of blogs written by - FreeBSD developers. Many developers use this to post quick + &os; developers. Many developers use this to post quick notes about what they are working on, new patches, and other works in progress. The BSDConferences YouTube Channel provides a collection of high quality videos from BSD Conferences around the world. This is a great way to watch key developers give presentations - about new work in FreeBSD. + about new work in &os;. Official Mirrors &chap.eresources.www.index.inc; &chap.mirrors.lastmod.inc; &chap.eresources.www.inc; Email Addresses - The following user groups provide FreeBSD related email + The following user groups provide &os; related email addresses for their members. The listed administrator reserves the right to revoke the address if it is abused in any way. Domain Facilities User Group Administrator ukug.uk.FreeBSD.org Forwarding only ukfreebsd@uk.FreeBSD.org Lee Johnston lee@uk.FreeBSD.org diff --git a/en_US.ISO8859-1/books/handbook/install/chapter.xml b/en_US.ISO8859-1/books/handbook/install/chapter.xml index d13933520c..b98ebd28c9 100644 --- a/en_US.ISO8859-1/books/handbook/install/chapter.xml +++ b/en_US.ISO8859-1/books/handbook/install/chapter.xml @@ -1,4938 +1,4891 @@ Jim Mock Restructured, reorganized, and parts rewritten by Randy Pratt The sysinstall walkthrough, screenshots, and general copy by - Installing &os; 8.<replaceable>X</replaceable> and Earlier + Installing &os; 8.<replaceable>X</replaceable> Synopsis installation - FreeBSD is provided with a text-based, easy to use installation + &os; provides a text-based, easy to use installation program. &os; 9.0-RELEASE and later use the installation program - known as bsdinstall, with releases prior - to 9.0-RELEASE using sysinstall for - installation. This chapter describes the use of sysinstall - to install &os;. The use of bsdinstall + known as &man.bsdinstall.8; + while &os; 8.X uses + &man.sysinstall.8;. This chapter describes + how to use &man.sysinstall.8;. + The use of &man.bsdinstall.8; is covered in . After reading this chapter, you will know: - How to create the FreeBSD installation disks. + How to create the &os; installation media. - How FreeBSD refers to, and subdivides, your hard disks. + How &os; refers to and subdivides hard disks. - How to start sysinstall. + How to start &man.sysinstall.8;. - The questions sysinstall will ask - you, what they mean, and how to answer them. + The questions &man.sysinstall.8; asks, + what they mean, and how to answer them. Before reading this chapter, you should: Read the supported hardware list that shipped with the version - of FreeBSD you are installing, and verify that your hardware is + of &os; to install, and verify that the system's hardware is supported. In general, these installation instructions are written - for &i386; (PC compatible) architecture - computers. Where applicable, instructions specific to other - platforms will be listed. Although this - guide is kept as up to date as possible, you may find minor - differences between the installer and what is shown here. It is - suggested that you use this chapter as a general guide rather + for the &i386; and &os;/&arch.amd64; architectures. + Where applicable, instructions specific to other + platforms will be listed. There may be minor + differences between the installer and what is shown here. + This chapter should be used as a general guide rather than a literal installation manual. Hardware Requirements Minimal Configuration The minimal configuration to install &os; varies with the &os; version and the hardware architecture. A summary of this information is given in the following sections. - Depending on the method you choose to install &os;, you may - also need a floppy drive, a supported CDROM drive, and in some - case a network adapter. This will be covered by the . + Depending on the method chosen to install &os;, + a floppy drive, CDROM drive, or + network adapter may be needed. Instructions on how to + prepare the installation media can be found in + . &os;/&arch.i386; and &os;/&arch.pc98; Both &os;/&arch.i386; and &os;/&arch.pc98; require a 486 or - better processor and at least 24 MB of RAM. You will - need at least 150 MB of free hard drive space for the + better processor, at least 24 MB of RAM, and at + least 150 MB of free hard drive space for the most minimal installation. - In case of old configurations, most of time, getting - more RAM and more hard drive space is more important than - getting a faster processor. + In the case of older hardware, installing more RAM and + more hard drive space is often more important than + a faster processor. &os;/&arch.amd64; There are two classes of processors capable of running &os;/&arch.amd64;. The first are AMD64 processors, including the &amd.athlon;64, - &amd.athlon;64-FX, &amd.opteron; or better + &amd.athlon;64-FX, and &amd.opteron; or better processors. - The second class of processors that can use - &os;/&arch.amd64; includes those using the &intel; EM64T + The second class of processors + includes those using the &intel; EM64T architecture. Examples of these processors include the &intel; &core; 2 Duo, Quad, Extreme processor families, and the &intel; &xeon; 3000, 5000, and 7000 sequences of processors. - If you have a machine based on an nVidia nForce3 - Pro-150, you must use the BIOS setup to - disable the IO APIC. If you do not have an option to do - this, you will likely have to disable ACPI instead. There - are bugs in the Pro-150 chipset that we have not found a - workaround for yet. + If the machine is based on an nVidia nForce3 + Pro-150, the BIOS setup must be used to + disable the IO APIC. If this option does not exist, + disable ACPI instead as there + are bugs in the Pro-150 chipset. &os;/&arch.sparc64; - To install &os;/&arch.sparc64;, you will need a supported + To install &os;/&arch.sparc64;, use a supported platform (see ). - You will need a dedicated disk for &os;/&arch.sparc64;. It - is not possible to share a disk with another operating + A dedicated disk is needed for &os;/&arch.sparc64; as + it is not possible to share a disk with another operating system at this time. Supported Hardware A list of supported hardware is provided with each &os; release in the &os; Hardware Notes. This document can usually be found in a file named HARDWARE.TXT, in - the top-level directory of a CDROM or FTP distribution or in - sysinstall's documentation menu. - It lists, for a given architecture, what hardware devices are + the top-level directory of a CDROM or FTP distribution, or in + &man.sysinstall.8;'s documentation menu. + It lists, for a given architecture, which hardware devices are known to be supported by each release of &os;. Copies of the supported hardware list for various releases and architectures can also be found on the Release - Information page of the &os; Web site. + Information page of the &os; website. Pre-installation Tasks - Inventory Your Computer + Inventory the Computer - Before installing &os; you should attempt to inventory the - components in your computer. The &os; installation routines will - show you the components (hard disks, network cards, CDROM drives, and - so forth) with their model number and manufacturer. &os; will also + Before installing &os; it is recommended to inventory the + components in the computer. The &os; installation routines + will show components such as hard disks, network cards, + and CDROM drives with their model number and manufacturer. + &os; will also attempt to determine the correct configuration for these devices, - which includes information about IRQ and IO port usage. Due to the - vagaries of PC hardware this process is not always completely - successful, and you may need to correct &os;'s determination of - your configuration. - - If you already have another operating system installed, such as - &windows; or Linux, it is a good idea to use the facilities provided - by those operating systems to see how your hardware is already - configured. If you are not sure what settings an expansion - card is using, you may find it printed on the card itself. Popular IRQ - numbers are 3, 5, and 7, and IO port addresses are normally written as - hexadecimal numbers, such as 0x330. - - We recommend you print or write down this information before - installing &os;. It may help to use a table, like this: + including information about IRQ and I/O port usage. Due + to the + vagaries of computer hardware, this process is not always + completely + successful, and &os; may need some manual + configuration. + + If another operating system is already installed, + use the facilities provided + by that operating systems to view the hardware configuration. + If the settings of an expansion + card are not obvious, check if they are printed on the + card itself. Popular IRQ + numbers are 3, 5, and 7, and I/O port addresses are normally + written as + hexadecimal numbers, such as 0x330. + + It is recommended to print or write down this information + before + installing &os;. It may help to use a table, as seen in this + example: Sample Device Inventory Device Name IRQ - IO port(s) + I/O port(s) Notes First hard disk N/A N/A 40 GB, made by Seagate, first IDE master CDROM N/A N/A First IDE slave Second hard disk N/A N/A 20 GB, made by IBM, second IDE master First IDE controller 14 0x1f0 Network card N/A N/A &intel; 10/100 Modem N/A N/A &tm.3com; 56K faxmodem, on COM1 …
- Once the inventory of the components in your computer is - done, you have to check if they match the hardware - requirements of the &os; release you want to install. + Once the inventory of the components in the computer is + complete, check if it matches the hardware + requirements of the &os; release to install. - Backup Your Data - - If the computer you will be installing &os; on contains - valuable data, then ensure you have it backed up, and that you have - tested the backups before installing &os;. The &os; - installation routine will prompt you before writing any - data to your disk, but once that process has started it cannot be + Make a Backup + + If the computer contains + valuable data, ensure it is backed up, and that the backup + has been + tested before installing &os;. The &os; + installer will prompt before writing any + data to disk, but once that process has started, it cannot be undone. Decide Where to Install &os; - If you want &os; to use your entire hard disk, then there is nothing - more to concern yourself with at this point — you can skip this + If &os; is to be installed on the entire hard disk, + skip this section. - However, if you need &os; to co-exist with other operating - systems then you need to have a rough understanding of how data is - laid out on the disk, and how this affects you. + However, if &os; will co-exist with other operating + systems, a rough understanding of how data is + laid out on the disk is useful. Disk Layouts for &os;/&arch.i386; - A PC disk can be divided into discrete chunks. These chunks are - called partitions. Since - &os; internally also has partitions, the naming - can become confusing very quickly, therefore these - disk chunks are referred to as disk slices or simply slices - in &os; itself. For example, the &os; utility - fdisk which operates on the PC disk partitions, + A PC disk can be divided into discrete chunks known as + partitions. Since + &os; also has partitions, naming + can quickly become confusing. Therefore, these + disk chunks are referred to as slices + in &os;. For example, the &os; version of + &man.fdisk.8; refers to slices instead of partitions. By design, the PC only supports four partitions per disk. These partitions are called primary partitions. To work around this limitation and allow more than four partitions, a new partition type was created, the extended partition. A disk may contain only one extended partition. Special partitions, called logical partitions, can be created inside this extended partition. Each partition has a partition ID, which is a number used to identify the type of data on the partition. &os; partitions have the partition ID of 165. - In general, each operating system that you use will identify - partitions in a particular way. For example, &ms-dos;, and its - descendants, like &windows;, assign each primary and logical partition a + In general, each operating system will identify + partitions in a particular way. For example, + &windows;, assigns each primary and logical partition a drive letter, starting with C:. - &os; must be installed into a primary partition. &os; can - keep all its data, including any files that you create, on this one - partition. However, if you have multiple disks, then you can create a - &os; partition on all, or some, of them. When you install &os;, - you must have one partition available. This might be a blank - partition that you have prepared, or it might be an existing partition - that contains data that you no longer care about. + &os; must be installed into a primary partition. If + there are multiple disks, a &os; + partition can be created + on all, or some, of them. When &os; is installed, at least + one partition must be available. This might be a blank + partition or it might be an existing partition whose + data can be overwritten. - If you are already using all the partitions on all your disks, then - you will have to free one of them for &os; using the tools - provided by the other operating systems you use (e.g., - fdisk on &ms-dos; or &windows;). + If all the partitions on all the disks are in use, + free one of them for &os; using the tools + provided by an existing operating system, such as &windows; + fdisk. - If you have a spare partition then you can use that. However, you - may need to shrink one or more of your existing partitions - first. + If there is a spare partition, use that. If it is too + small, + shrink one or more existing partitions to create more + available space. A minimal installation of &os; takes as little as 100 MB of disk space. However, that is a very minimal install, - leaving almost no space for your own files. A more realistic minimum + leaving almost no space for files. A more realistic minimum is 250 MB without a graphical environment, and 350 MB or - more if you - want a graphical user interface. If you intend to install a lot of - third-party software as well, then you will need more space. + more for + a graphical user interface. If other + third-party software will be installed, + even more space is needed. You can use a tool such as GParted to resize your partitions and make space for &os;. GParted is known to work on NTFS and is available on a number of Live CD Linux distributions, such as SystemRescueCD. - Problems have been reported resizing µsoft; Vista - partitions. Having a Vista installation CDROM handy when - attempting such an operation is recommended. As with all - such disk maintenance tasks, a current set of backups is - also strongly advised. - - Incorrect use of these tools can delete the data on your disk. - Be sure that you have recent, working backups before using - them. + Incorrect use of a shrinking tool can delete the data + on the disk. + Always have a recent, working backup before using this + type of tool. Using an Existing Partition Unchanged - Suppose that you have a computer with a single 4 GB disk + Consider a computer with a single 4 GB disk that - already has a version of &windows; installed, and you have split the - disk into two drive letters, C: and + already has a version of &windows; installed, where the + disk has been split into two drive letters, + C: and D:, each of which is 2 GB in size. - You have 1 GB of data on C:, and + There is 1 GB of data on C:, + and 0.5 GB of data on D:. - This means that your disk has two partitions on it, one per - drive letter. You can copy all your existing data from + This disk has two partitions, one per + drive letter. Copy all existing data from D: to C:, which will free up the second partition, ready for &os;. Shrinking an Existing Partition - Suppose that you have a computer with a single 4 GB disk - that already has a version of &windows; installed. When you installed - &windows; you created one large partition, giving you a - C: drive that is 4 GB in size. You are - currently using 1.5 GB of space, and want &os; to have 2 GB + Consider a computer with a single 4 GB disk + that already has a version of &windows; installed. When + &windows; was installed, it created one large partition, + a + C: drive that is 4 GB in size. + Currently, 1.5 GB of space is used, and &os; should + have 2 GB of space. - In order to install &os; you will need to either: + In order to install &os;, either: - Backup your &windows; data, and then reinstall &windows;, + Backup the &windows; data and then reinstall + &windows;, asking for a 2 GB partition at install time. Use one of the tools described above to shrink your &windows; partition. - Collect Your Network Configuration Details + Collect the Network Configuration Details - If you intend to connect to a network as part of your &os; - installation (for example, if you will be installing from an FTP + Before + installing from an FTP site or an - NFS server), then you need to know your network configuration. You - will be prompted for this information during the installation so that - &os; can connect to the network to complete the install. + NFS server, make note of the network + configuration. The + installer + will prompt for this information so that + it can connect to the network to complete the + installation. Connecting to an Ethernet Network or Cable/DSL Modem - If you connect to an Ethernet network, or you have an Internet - connection using an Ethernet adapter via cable or DSL, then you will - need the following information: + If using an Ethernet network or an Internet + connection using an Ethernet adapter via cable or DSL, the + following information is needed: IP address IP address of the default gateway Hostname DNS server IP addresses Subnet Mask - If you do not know this information, then ask your system - administrator or service provider. They may say that this - information is assigned automatically, using - DHCP. If so, make a note of this. + If this information is unknown, ask the system + administrator or service provider. Make note if this + information is assigned automatically using + DHCP. Connecting Using a Modem - If you dial up to an ISP using a regular modem then you can - still install &os; over the Internet, it will just take a very + If using a dialup modem, + &os; can still be installed over the Internet, it will just + take a very long time. You will need to know: - The phone number to dial for your ISP + The phone number to dial the Internet Service + Provider (ISP) - The COM: port your modem is connected to + The COM: port the modem is connected to - The username and password for your ISP account + The username and password for the + ISP account Check for &os; Errata - Although the &os; project strives to ensure that each release + Although the &os; Project strives to ensure that each + release of &os; is as stable as possible, bugs do occasionally creep into - the process. On very rare occasions those bugs affect the + the process. On rare occasions those bugs affect the installation process. As these problems are discovered and fixed, they are noted in the &os; Errata, - which is found on the &os; web site. You - should check the errata before installing to make sure that there are - no late-breaking problems which you should be aware of. + which is found on the &os; website. + Check the errata before installing to make sure that there are + no late-breaking problems to be aware of. - Information about all the releases, including the errata for each + Information about all releases, including the errata for + each release, can be found on the release information section of the &os; web site. + url="&url.base;/index.html">&os; website. Obtain the &os; Installation Files - The &os; installation process can install &os; from files + The &os; installer can install &os; from files located in any of the following places: Local Media A CDROM or DVD A USB Memory Stick A &ms-dos; partition on the same computer - A SCSI or QIC tape - - - - Floppy disks + Floppy disks (&os;/&arch.pc98; only) Network - An FTP site, going through a firewall, or using an HTTP proxy, - as necessary + An FTP site through a firewall or using an HTTP + proxy An NFS server A dedicated parallel or serial connection - If you have purchased &os; on CD or DVD then you already have - everything you need, and should proceed to the next section - (). + If installing from a purchased &os; CD/DVD, + skip ahead to + . - If you have not obtained the &os; installation files you should + To obtain the &os; installation files, skip ahead to which explains how - to prepare to install &os; from any of the above. After reading - that section, you should come back here, and read on to + to prepare the installation media. After reading + that section, come back here and read on to . Prepare the Boot Media The &os; installation process is started by booting the - computer into the &os; installer—it is not a program you run + computer into the &os; installer. It is not a program that + can be run within another operating system. The computer normally boots using the operating system installed on the hard disk, but it can also be configured to boot from a CDROM or from a USB disk. - If you have &os; on CDROM or DVD (either one you purchased - or you prepared yourself), and your computer allows you to boot from - the CDROM or DVD (typically a BIOS option called Boot - Order or similar), then you can skip this section. The - &os; CDROM and DVD images are bootable and can be used to install + If installing from a CD/DVD to a + computer whose BIOS supports booting from + the CD/DVD, skip this section. The + &os; CD/DVD images are bootable and can be used to + install &os; without any other special preparation. To create a bootable memory stick, follow these steps: Acquire the Memory Stick Image Memory stick images for - &os; 8.X and earlier can be downloaded from + &os; 8.X can be downloaded + from the ISO-IMAGES/ directory at ftp://ftp.FreeBSD.org/pub/FreeBSD/releases/arch/ISO-IMAGES/version/&os;-version-RELEASE-arch-memstick.img. Replace arch and version with the - architecture and the version number which you want to - install, respectively. For example, the memory stick + architecture and the version number to + install. For example, the memory stick images for &os;/&arch.i386; &rel2.current;-RELEASE are available from . A different directory path is used for - &os; 9.0-RELEASE and later versions. Details of - download and installation of &os; 9.0-RELEASE and - later is covered in . + &os; 9.0-RELEASE and later versions. How to + download and install + &os; 9.X + is covered in . The memory stick image has a .img extension. The ISO-IMAGES/ directory - contains a number of different images, and the one you - will need to use will depend on the version of &os; you - are installing, and in some cases, the hardware you are - installing to. + contains a number of different images and the one to + use depends on the version of &os; and the + type of media supported by the hardware being installed + to. Before proceeding, back up the - data you currently have on your USB stick, as this + data on the USB stick, as this procedure will erase it. Write the Image File to the Memory Stick Using &os; to Write the Image The example below lists /dev/da0 as the target device where the image will be written. Be very careful that you have the correct device as the output target, or you may destroy your existing data. Writing the Image with &man.dd.1; The .img file - is not a regular file you copy to the + is not a regular file that can + just be copied to the memory stick. It is an image of the complete contents of the - disk. This means that you cannot simply - copy files from one disk to another. Instead, you must use - &man.dd.1; to write the image directly to the disk: + disk. This means that + &man.dd.1; must be used to write the image directly to + the disk: &prompt.root; dd if=&os;-&rel2.current;-RELEASE-&arch.i386;-memstick.img of=/dev/da0 bs=64k If an Operation not permitted error is displayed, make certain that the target device - is not in use, mounted, or being automounted by some - well-intentioned utility program. Then try + is not in use, mounted, or being automounted by + another program. Then try again. Using &windows; to Write the Image - Make sure you use the correct drive letter as the output - target, or you may overwrite and destroy existing data. + Make sure to use the correct drive letter as the + output + target, as this command will overwrite and destroy + any existing data on the specified device. Obtaining <application>Image Writer for Windows</application> Image Writer for Windows is a free application that can correctly write an image file to a memory stick. Download it from and extract it into a folder. Writing the Image with Image Writer Double-click the Win32DiskImager icon to start the program. Verify that the drive letter shown under Device is the drive with the memory stick. Click the folder icon and select the image to be written to the memory stick. Click Save to accept the image file name. Verify that everything is correct, and that no folders on the memory stick are open in other windows. Finally, click Write to write the image file to the drive. To create the boot floppy images for a &os;/&arch.pc98; installation, follow these steps: Acquire the Boot Floppy Images The &os;/&arch.pc98; boot disks can be downloaded from the floppies directory, ftp://ftp.FreeBSD.org/pub/FreeBSD/releases/pc98/version-RELEASE/floppies/. Replace version with the version number to install. The floppy images have a .flp extension. floppies/ contains a number of different images. Download boot.flp as well as the number of files associated with the type of installation, such as kern.small* or kern*. - Your FTP program must use binary mode - to download these disk images. Some web browsers have been - known to use text (or - ASCII) mode, which will be apparent if you - cannot boot from the disks. + The FTP program must use binary + mode + to download these disk images. Some web browsers + use text or + ASCII mode, which will be apparent + if + the disks are not bootable. Prepare the Floppy Disks - Prepare one floppy disk per image file you had to - download. It is imperative that these disks are free from - defects. The easiest way to test this is to format the disks - for yourself. Do not trust pre-formatted floppies. The format + Prepare one floppy disk per downloaded image file. + It is imperative that these disks are free from + defects. The easiest way to test this is to reformat the + disks. + Do not trust pre-formatted floppies. The format utility in &windows; will not tell about the presence of bad blocks, it simply marks them as bad - and ignores them. It is advised that you use brand new - floppies if choosing this installation route. + and ignores them. It is advised to use brand new + floppies. - If you try to install &os; and the installation - program crashes, freezes, or otherwise misbehaves, one of + If the installer + crashes, freezes, or otherwise misbehaves, one of the first things to suspect is the floppies. Write the floppy image files to new disks and try again. Write the Image Files to the Floppy Disks The .flp files are - not regular files you copy to the disk. + not regular files that can be copied + to the disk. They are images of the complete contents of the - disk. This means that you cannot simply - copy files from one disk to another. - Instead, you must use specific tools to write the + disk. + Specific tools must be used to write the images directly to the disk. DOS - If you are creating the floppies on a computer running - &ms-dos; / &windows;, then we provide a tool to do - this called fdimage. - - If you are using the floppies from the CDROM, and your - CDROM is the E: drive, then you would - run this: - - E:\> tools\fdimage floppies\boot.flp A: + &os; provides a tool called + rawrite for creating the floppies on a + computer running + &windows;. This tool can be downloaded from + ftp://ftp.FreeBSD.org/pub/FreeBSD/releases/pc98/ + version-RELEASE/tools/ + on the &os; FTP site. Download this tool, insert a + floppy, then specify the filename to write to the floppy + drive: + + C:\> rawrite boot.flp A: Repeat this command for each .flp file, replacing the floppy disk each time, being sure to label - the disks with the name of the file that you copied to them. - Adjust the command line as necessary, depending on where you have - placed the .flp files. If you do not have - the CDROM, then fdimage can be downloaded from - the tools - directory on the &os; FTP site. - - If you are writing the floppies on a &unix; system (such as - another &os; system) you can use the &man.dd.1; command to - write the image files directly to disk. On &os;, you would + the disks with the name of the file. + Adjust the command line as necessary, depending on where + the .flp files are located. + + When writing the floppies on a &unix;-like system, + such as + another &os; system, use &man.dd.1; to + write the image files directly to disk. On &os;, run: &prompt.root; dd if=boot.flp of=/dev/fd0 On &os;, /dev/fd0 refers to the - first floppy disk (the A: drive). - /dev/fd1 would be the - B: drive, and so on. Other &unix; + first floppy disk. Other &unix; variants might have different names for the floppy disk - devices, and you will need to check the documentation for the + device, so check the documentation for the system as necessary. You are now ready to start installing &os;. Starting the Installation - By default, the installation will not make any changes to your - disk(s) until you see the following message: + By default, the installer will not make any changes to + the + disk(s) until after the following message: Last Chance: Are you SURE you want continue the installation? If you're running this on a disk with data you wish to save then WE STRONGLY ENCOURAGE YOU TO MAKE PROPER BACKUPS before proceeding! We can take no responsibility for lost disk contents! - The install can be exited at any time prior to the final - warning without changing the contents of the hard drive. If you are - concerned that you have configured something incorrectly you can just - turn the computer off before this point, and no damage will be + The install can be exited at any time prior to this final + warning without changing the contents of the hard drive. If + there is a + concern that something is configured incorrectly, + turn the computer off before this point, and no damage + will be done. Booting Booting for the &i386; - - Start with your computer turned off. - - Turn on the computer. As it starts it should display an option to enter the system set up menu, or BIOS, commonly reached by keys like F2, F10, Del, or Alt S . Use whichever keystroke is indicated on screen. In - some cases your computer may display a graphic while it starts. + some cases the computer may display a graphic while it + starts. Typically, pressing Esc will dismiss the graphic - and allow you to see the necessary messages. + and display the boot messages. Find the setting that controls which devices the system boots from. This is usually labeled as the Boot Order and commonly shown as a list of devices, such as Floppy, CDROM, First Hard Disk, and so on. - If you are booting from the CDROM then make sure that - the CDROM is selected. If you are booting from a USB disk or - a floppy disk then - make sure that is selected instead. In case of doubt, you - should consult the manual that came with your computer, and/or its + If booting from the CD/DVD, make sure that + the CDROM drive is selected. If booting from a USB disk, + make sure that it is selected instead. When in doubt, + consult the manual that came with the computer or its motherboard. Make the change, then save and exit. The computer should now restart. - If you prepared a bootable USB stick, as described in - , then plug in your USB + If using a prepared a bootable USB + stick, as described in + , plug in the USB stick before turning on the computer. - If you are booting from CDROM, then you will need to turn on - the computer, and insert the CDROM at the first + If booting from CD/DVD, turn on + the computer, and insert the CD/DVD at the first opportunity. For &os;/&arch.pc98;, installation boot floppies are available and can be prepared as described in . The first floppy disc will contain boot.flp. Put this floppy in the floppy drive to boot into the installer. - If your computer starts up as normal and loads your existing + If the computer starts up as normal and loads the + existing operating system, then either: The disks were not inserted early enough in the boot - process. Leave them in, and try restarting your + process. Leave them in, and try restarting the computer. - The BIOS changes earlier did not work correctly. You - should redo that step until you get the right option. + The BIOS changes did not work correctly. + Redo that step until the right option is + selected. - Your particular BIOS does not support booting from + That particular BIOS does not support booting from the desired media. - &os; will start to boot. If you are booting from CDROM you - will see a display similar to this (version information - omitted): + &os; will start to boot. If booting from CD/DVD, + messages will be displayed, similar to these: Booting from CD-Rom... 645MB medium detected CD Loader 1.2 Building the boot loader arguments Looking up /BOOT/LOADER... Found Relocating the loader and the BTX Starting the BTX loader BTX loader 1.00 BTX version is 1.02 Consoles: internal video/keyboard BIOS CD is cd0 BIOS drive C: is disk0 BIOS drive D: is disk1 BIOS 636kB/261056kB available memory FreeBSD/i386 bootstrap loader, Revision 1.1 Loading /boot/defaults/loader.conf /boot/kernel/kernel text=0x64daa0 data=0xa4e80+0xa9e40 syms=[0x4+0x6cac0+0x4+0x88e9d] \ - If you are booting from floppy disc, you will see a display - similar to this (version information omitted): + If booting from floppy disc, a display + similar to this will be shown: Booting from Floppy... Uncompressing ... done BTX loader 1.00 BTX version is 1.01 Console: internal video/keyboard BIOS drive A: is disk0 BIOS drive C: is disk1 BIOS 639kB/261120kB available memory FreeBSD/i386 bootstrap loader, Revision 1.1 Loading /boot/defaults/loader.conf /kernel text=0x277391 data=0x3268c+0x332a8 | Insert disk labelled "Kernel floppy 1" and press any key... - Follow these instructions by removing the - boot.flp disc, insert the - kern1.flp disc, and press - Enter. Boot from first floppy; - when prompted, insert the other disks as required. + Remove the + boot.flp floppy, insert the + next floppy, and press + Enter. + When prompted, insert the other disks as required. - Whether you booted from CDROM, USB stick or floppy, the - boot process will then get to the &os; boot loader + The + boot process will then display the &os; boot loader menu:
&os; Boot Loader Menu
Either wait ten seconds, or press Enter. Booting for &sparc64; - Most &sparc64; systems are set up to boot automatically - from disk. To install &os;, you need to boot over the - network or from a CDROM, which requires you to break into - the PROM (OpenFirmware). - - To do this, reboot the system, and wait until the boot - message appears. It depends on the model, but should look - about like: + Most &sparc64; systems are set to boot automatically + from disk. To install &os;, boot over the + network or from a CD/DVD and wait until the boot + message appears. The message depends on the model, but + should look similar to: Sun Blade 100 (UltraSPARC-IIe), Keyboard Present Copyright 1998-2001 Sun Microsystems, Inc. All rights reserved. OpenBoot 4.2, 128 MB memory installed, Serial #51090132. Ethernet address 0:3:ba:b:92:d4, Host ID: 830b92d4. - If your system proceeds to boot from disk at this point, - you need to press + If the system proceeds to boot from disk, + press L1A or StopA on the keyboard, or send a BREAK over the - serial console (using for example ~# in - &man.tip.1; or &man.cu.1;) to get to the PROM prompt. It + serial console using ~# in + &man.tip.1; or &man.cu.1; to get to the PROM prompt. It looks like this: ok ok {0} This is the prompt used on systems with just one CPU. - This is the prompt used on SMP systems, the digit + This is the prompt used on SMP systems and the + digit indicates the number of the active CPU. - At this point, place the CDROM into your drive, and from + At this point, place the CD/DVD into the drive and from the PROM prompt, type boot cdrom. Reviewing the Device Probe Results The last few hundred lines that have been displayed on screen are stored and can be reviewed. - To review the buffer, press Scroll Lock. This - turns on scrolling in the display. You can then use the arrow keys, or + To review this buffer, press Scroll Lock + to + turn on scrolling in the display. Use the arrow keys or PageUp and PageDown to view the results. Press Scroll Lock again to stop scrolling. Do this now, to review the text that scrolled off the screen when - the kernel was carrying out the device probes. You will see text - similar to , although the precise - text will differ depending on the devices that you have in your + the kernel was carrying out the device probes. Text + similar to will be + displayed, although + it will differ depending on the devices in the computer.
Typical Device Probe Results avail memory = 253050880 (247120K bytes) Preloaded elf kernel "kernel" at 0xc0817000. Preloaded mfs_root "/mfsroot" at 0xc0817084. md0: Preloaded image </mfsroot> 4423680 bytes at 0xc03ddcd4 md1: Malloc disk Using $PIR table, 4 entries at 0xc00fde60 npx0: <math processor> on motherboard npx0: INT 16 interface pcib0: <Host to PCI bridge> on motherboard pci0: <PCI bus> on pcib0 pcib1:<VIA 82C598MVP (Apollo MVP3) PCI-PCI (AGP) bridge> at device 1.0 on pci0 pci1: <PCI bus> on pcib1 pci1: <Matrox MGA G200 AGP graphics accelerator> at 0.0 irq 11 isab0: <VIA 82C586 PCI-ISA bridge> at device 7.0 on pci0 isa0: <iSA bus> on isab0 atapci0: <VIA 82C586 ATA33 controller> port 0xe000-0xe00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0 <VIA 83C572 USB controller> port 0xe400-0xe41f irq 10 at device 7.2 on pci 0 usb0: <VIA 83572 USB controller> on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr1 uhub0: 2 ports with 2 removable, self powered pci0: <unknown card> (vendor=0x1106, dev=0x3040) at 7.3 dc0: <ADMtek AN985 10/100BaseTX> port 0xe800-0xe8ff mem 0xdb000000-0xeb0003ff ir q 11 at device 8.0 on pci0 dc0: Ethernet address: 00:04:5a:74:6b:b5 miibus0: <MII bus> on dc0 ukphy0: <Generic IEEE 802.3u media interface> on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ed0: <NE2000 PCI Ethernet (RealTek 8029)> port 0xec00-0xec1f irq 9 at device 10. 0 on pci0 ed0 address 52:54:05:de:73:1b, type NE2000 (16 bit) isa0: too many dependant configs (8) isa0: unexpected small tag 14 orm0: <Option ROM> at iomem 0xc0000-0xc7fff on isa0 fdc0: <NEC 72065B or clone> at port 0x3f0-0x3f5,0x3f7 irq 6 drq2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5” drive> on fdc0 drive 0 atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0 atkbd0: <AT Keyboard> flags 0x1 irq1 on atkbdc0 kbd0 at atkbd0 psm0: <PS/2 Mouse> irq 12 on atkbdc0 psm0: model Generic PS/@ mouse, device ID 0 vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 sc0: <System console> at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc0: <Parallel port> at port 0x378-0x37f irq 7 on isa0 pppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/15 bytes threshold plip0: <PLIP network interface> on ppbus0 ad0: 8063MB <IBM-DHEA-38451> [16383/16/63] at ata0-master UDMA33 acd0: CD-RW <LITE-ON LTR-1210B> at ata1-slave PIO4 Mounting root from ufs:/dev/md0c /stand/sysinstall running as init on vty0
Check the probe results carefully to make sure that &os; found - all the devices you expected. If a device was not found, then it will + all the devices. If a device was not found, it will not be listed. A custom kernel - allows you to add in support for devices which are not in the - GENERIC kernel, such as sound cards. + can be used to add in support for devices which are not in the + GENERIC kernel. - After the procedure of device - probing, you will see . Use the + After the device + probe, the menu shown in + will be displayed. Use the arrow key to choose a country, region, or group. Then press - Enter, it will set your country - easily. + Enter to set the country.
Selecting Country Menu
- If you selected United States - as country, the standard American keyboard map will be used, - if a different country is chosen the following menu will be + If United States is selected + as the country, the standard American keyboard map will be + used. + If a different country is chosen, the following menu will be displayed. Use the arrow keys to choose the correct keyboard map and press Enter.
Selecting Keyboard Menu
- After the country selecting, the sysinstall + After the country selection, the &man.sysinstall.8; main menu will display. - Introducing Sysinstall + Introducing &man.sysinstall.8; - The sysinstall utility is the installation - application provided by the &os; Project. It is console based and is - divided into a number of menus and screens that you can use to + The &os; 8.X installer, + &man.sysinstall.8;, is console based and + is + divided into a number of menus and screens that can be used to configure and control the installation process. - The sysinstall menu system is controlled + This menu system is controlled by the arrow keys, Enter, Tab, Space, and - other keys. A detailed description of these keys and what they do is - contained in sysinstall's usage - information. - - To review this information, ensure that the + other keys. To view a detailed description of these keys and + what they do, ensure that the Usage entry is highlighted and that the [Select] button is selected, as shown in , then press Enter. The instructions for using the menu system will be displayed. After reviewing them, press Enter to return to the Main Menu.
Selecting Usage from Sysinstall Main Menu
Selecting the Documentation Menu From the Main Menu, select Doc with the arrow keys and press Enter.
Selecting Documentation Menu
This will display the Documentation Menu.
Sysinstall Documentation Menu
- It is important to read the documents provided. - - To view a document, select it with the arrow keys and + It is important to read the documents provided. To view a + document, select it with the arrow keys and press Enter. When finished reading a document, - pressing Enter will return to the Documentation + press Enter to return to the Documentation Menu. To return to the Main Installation Menu, select Exit with the arrow keys and press Enter. Selecting the Keymap Menu To change the keyboard mapping, use the arrow keys to select Keymap from the menu and press - Enter. This is only required if you are + Enter. This is only required when using a non-standard or non-US keyboard.
Sysinstall Main Menu
A different keyboard mapping may be chosen by selecting the - menu item using up/down arrow keys and pressing Space. + menu item using the up and down arrow keys and pressing + Space. Pressing Space again will unselect the item. When finished, choose the &gui.ok; using the arrow keys and press Enter. Only a partial list is shown in this screen representation. Selecting &gui.cancel; by pressing Tab will use the default keymap and return to the Main Install Menu.
Sysinstall Keymap Menu
Installation Options Screen Select Options and press Enter.
Sysinstall Main Menu
Sysinstall Options
The default values are usually fine for most users and do not need to be changed. The release name will vary according to the version being installed. The description of the selected item will appear at the bottom of the screen highlighted in blue. Notice that one of the options is Use Defaults to reset all values to startup defaults. Press F1 to read the help screen about the various options. - Pressing Q will return to the Main Install + Press Q to return to the Main Install menu. Begin a Standard Installation The Standard installation is the option recommended for those new to &unix; or &os;. Use the arrow keys to select Standard and then press Enter to start the installation.
Begin Standard Installation
Allocating Disk Space - Your first task is to allocate disk space for &os;, and label - that space so that sysinstall can prepare + The first task is to allocate disk space for &os;, and label + that space so that &man.sysinstall.8; can prepare it. In order to do this you need to know how &os; expects to find information on the disk. BIOS Drive Numbering Before installing and configuring &os; it is important to be aware how &os; deals with BIOS drive mappings. MS-DOS Microsoft Windows In a PC running a BIOS-dependent operating system such as - &ms-dos; or µsoft.windows;, the BIOS is able to abstract the - normal disk drive order, and + µsoft.windows;, the BIOS is able to abstract the + normal disk drive order and the operating system goes along with the change. This allows the user to boot from a disk drive other than the "primary master". This is especially convenient for users buy an identical second hard drive, and perform routine copies of the first drive to the second drive. If the first drive fails, is attacked by a virus, or is scribbled upon by an operating system defect, they can easily recover by instructing the BIOS to logically swap the drives. It is like switching the cables on the - drives, but without having to open the case. + drives, without having to open the case. SCSI BIOS - More expensive systems with SCSI controllers often include BIOS + Systems with SCSI controllers often include BIOS extensions which allow the SCSI drives to be re-ordered in a similar fashion for up to seven drives. A user who is accustomed to taking advantage of these features may become surprised when the results with &os; are not as expected. &os; does not use the BIOS, and does not know the logical BIOS - drive mapping. This can lead to very perplexing situations, - especially when drives are physically identical in geometry, and have - also been made as data clones of one another. + drive mapping. This can lead to perplexing + situations, + especially when drives are physically identical in geometry + and have + been made as data clones of one another. When using &os;, always restore the BIOS to natural drive - numbering before installing &os;, and then leave it that way. If you - need to switch drives around, then do so, but do it the hard way, and + numbering before installing &os;, and then leave it that way. + If drives + need to be switched around, take the time to open the case and move the jumpers and cables. An Illustration from the Files of Bill and Fred's Exceptional Adventures: Bill breaks-down an older Wintel box to make another &os; box for Fred. Bill installs a single SCSI drive as SCSI unit zero and installs &os; on it. Fred begins using the system, but after several days notices that - the older SCSI drive is reporting numerous soft errors and reports - this fact to Bill. - - After several more days, Bill decides it is time to address the - situation, so he grabs an identical SCSI drive from the disk drive - archive in the back room. An initial surface scan - indicates that - this drive is functioning well, so Bill installs this drive as SCSI + the older SCSI drive is reporting numerous + errors. + + To address the + situation, Bill grabs an identical SCSI drive and installs + this drive as SCSI unit four and makes an image copy from drive zero to drive four. Now - that the new drive is installed and functioning nicely, Bill decides - that it is a good idea to start using it, so he uses features in the + that the new drive is installed and functioning, Bill + decides + to start using it, so he uses features in the SCSI BIOS to re-order the disk drives so that the system boots from SCSI unit four. &os; boots and runs just fine. - Fred continues his work for several days, and soon Bill and Fred - decide that it is time for a new adventure — time to upgrade + Fred continues his work and soon + decides that it is time to upgrade to a newer version of &os;. Bill removes SCSI unit zero because it was - a bit flaky and replaces it with another identical disk drive from - the archive. Bill then installs the new version of - &os; onto the new SCSI unit zero using Fred's magic Internet FTP - floppies. The installation goes well. + a bit flaky and replaces it with another identical disk + drive. Bill then installs the new version of + &os; onto the new SCSI unit zero and the installation goes + well. Fred uses the new version of &os; for a few days, and certifies that it is good enough for use in the engineering department. It is - time to copy all of his work from the old version. So Fred mounts - SCSI unit four (the latest copy of the older &os; version). Fred - is dismayed to find that none of his precious work is present on SCSI + time to copy all of his work from the old version, so Fred + mounts + SCSI unit four which should contain the latest copy of the + older + &os; version. Fred + is dismayed to find that none of his work is present on SCSI unit four. - Where did the data go? - - When Bill made an image copy of the original SCSI unit zero onto + It turns out that when Bill made an image copy of the + original SCSI unit zero onto SCSI unit four, unit four became the new clone. When Bill re-ordered the SCSI BIOS so that he could boot from - SCSI unit four, he was only fooling himself. + SCSI unit four, &os; was still running on SCSI unit zero. - Making this kind of BIOS change will cause some or all of the Boot and - Loader code to be fetched from the selected BIOS drive, but when the - &os; kernel drivers take-over, the BIOS drive numbering will be - ignored, and &os; will transition back to normal drive numbering. - In the illustration at hand, the system continued to operate on the + Making this kind of BIOS change causes some or all of the + boot and + loader code to be fetched from the selected BIOS drive. But + when the + &os; kernel drivers take over, the BIOS drive numbering is + ignored, and &os; transitions back to normal drive + numbering. + In this example, the system continued to operate on the original SCSI unit zero, and all of Fred's data was there, not on SCSI unit four. The fact that the system appeared to be running on SCSI unit four was simply an artifact of human expectations. - We are delighted to mention that no data bytes were killed or - harmed in any way by our discovery of this phenomenon. The older SCSI - unit zero was retrieved from the bone pile, and all of Fred's work was - returned to him, (and now Bill knows that he can count as high as - zero). + Fortunately, the older SCSI + unit zero was retrieved and all of Fred's work was + restored. Although SCSI drives were used in this illustration, the concepts apply equally to IDE drives. Creating Slices Using FDisk - - No changes you make at this point will be written to the disk. - If you think you have made a mistake and want to start again you can - use the menus to exit sysinstall and try - again or press U to use the - Undo option. - If you get confused and can not see how to exit you can - always turn your computer off. - - After choosing to begin a standard installation in - sysinstall you will be shown this - message: + &man.sysinstall.8;, this + message will appear: Message In the next menu, you will need to set up a DOS-style ("fdisk") partitioning scheme for your hard disk. If you simply wish to devote all disk space to FreeBSD (overwriting anything else that might be on the disk(s) selected) then use the (A)ll command to select the default partitioning scheme followed by a (Q)uit. If you wish to allocate only free space to FreeBSD, move to a partition marked "unused" and use the (C)reate command. [ OK ] [ Press enter or space ] - Press Enter as instructed. You will then be - shown a list of all the hard drives that the kernel found when it - carried out the device probes. + Press Enter and + a list of all the hard drives that the kernel found when it + carried out the device probes will be displayed. shows an example from a - system with two IDE disks. They have been called + system with two IDE disks called ad0 and ad2.
Select Drive for FDisk
- You might be wondering why ad1 is not - listed here. Why has it been missed? + Note that ad1 is not + listed here. - Consider what would happen if you had two IDE hard disks, one - as the master on the first IDE controller, and one as the master on - the second IDE controller. If &os; numbered these as it found - them, as ad0 and - ad1 then everything would work. + Consider two IDE hard disks where one + is the master on the first IDE controller and one is the + master on + the second IDE controller. If &os; numbered these as + ad0 and + ad1, everything would work. - But if you then added a third disk, as the slave device on the + But if a third disk is later added as the slave device on + the first IDE controller, it would now be ad1, and the previous ad1 would become - ad2. Because device names (such as - ad1s1a) are used to find filesystems, you - may suddenly discover that some of your filesystems no longer - appear correctly, and you would need to change your &os; + ad2. Because device names + are used to find filesystems, + some filesystems may no longer + appear correctly, requiring a change to the &os; configuration. To work around this, the kernel can be configured to name IDE - disks based on where they are, and not the order in which they were - found. With this scheme the master disk on the second IDE + disks based on where they are and not the order in which they + were + found. With this scheme, the master disk on the second IDE controller will always be ad2, even if there are no ad0 or ad1 devices. This configuration is the default for the &os; kernel, which - is why this display shows ad0 and + is why the display in this example shows + ad0 and ad2. The machine on which this screenshot was taken had IDE disks on both master channels of the IDE - controllers, and no disks on the slave channels. + controllers and no disks on the slave channels. - You should select the disk on which you want to install &os;, + Select the disk on which to install &os;, and then press &gui.ok;. FDisk will start, with a display similar to that shown in . The FDisk display is broken into three sections. The first section, covering the first two lines of the display, shows details about the currently selected disk, including its &os; name, the disk geometry, and the total size of the disk. The second section shows the slices that are currently on the disk, where they start and end, how large they are, the name &os; gives them, and their description and sub-type. This example shows two - small unused slices, which are artifacts of disk layout schemes on the + small unused slices which are artifacts of disk layout schemes + on the PC. It also shows one large FAT slice, which - almost certainly appears as C: in - &ms-dos; / &windows;, and an extended slice, which may contain other - drive letters for &ms-dos; / &windows;. + appears as C: in + &windows;, and an extended slice, which may contain other + drive letters in &windows;. The third section shows the commands that are available in FDisk.
- Typical <command>fdisk</command> Partitions Before Editing + Typical Default <application>FDisk</application> + Partitions
- What you do now will depend on how you want to slice up your - disk. + This step varies, depending on how the disk is to be + sliced. - If you want to use &os; for the entire disk (which will delete - all the other data on this disk when you confirm that you want - sysinstall to continue later in the - installation process) then you can press A, which + To install &os; to the entire disk, which will delete + all the other data on this disk, press A, + which corresponds to the Use Entire Disk option. - The existing slices will be removed, and replaced with a small area - flagged as unused (again, an artifact of PC disk - layout), and then one large slice for &os;. If you do this, then - you should select the newly created &os; slice using the arrow - keys, and press S to mark the slice as being - bootable. The screen will then look very similar to + The existing slices will be removed and replaced with a small + area + flagged as unused + and one large slice for &os;. Then, + select the newly created &os; slice using the arrow + keys and press S to mark the slice as being + bootable. The screen will then look similar to . Note the A in the Flags column, which indicates that this slice is active, and will be booted from. - If you will be deleting an existing slice to make space for - &os; then you should select the slice using the arrow keys, and - then press D. You can then press C, - and be prompted for size of slice you want to create. Enter the - appropriate figure and press Enter. The default - value in this box represents the largest possible slice you can + If an existing slice needs to be deleted to make space for + &os;, select the slice using the arrow keys and + press D. Then, press C to + be prompted for the size of the slice to create. Enter the + appropriate value and press Enter. The + default + value in this box represents the largest possible slice to make, which could be the largest contiguous block of unallocated space or the size of the entire hard disk. If you have already made space for &os; then you can press C to create a new slice. Again, you will be prompted for the size of slice you would like to create.
Fdisk Partition Using Entire Disk
- When finished, press Q. Your changes will be - saved in sysinstall, but will not yet be + When finished, press Q. Any changes will + be + saved in &man.sysinstall.8;, but will not yet be written to disk. Install a Boot Manager - You now have the option to install a boot manager. In general, - you should choose to install the &os; boot manager if: + The next menu provides the option to install a boot + manager. In general, + install the &os; boot manager if: - You have more than one drive, and have installed &os; onto + There is more than one drive and &os; will be + installed onto a drive other than the first one. - You have installed &os; alongside another operating system + &os; will be installed alongside another operating + system on the same disk, and you want to choose whether to start &os; - or the other operating system when you start the computer. + or the other operating system when the computer + starts. If &os; is going to be the only operating system on this machine, installed on the first hard disk, then the Standard boot manager will suffice. - Choose None if you are using a + Choose None if using a third-party boot manager capable of booting &os;. - Make your choice and press Enter. + Make a selection and press Enter.
Sysinstall Boot Manager Menu
The help screen, reached by pressing F1, discusses the problems that can be encountered when trying to share the hard disk between operating systems. Creating Slices on Another Drive If there is more than one drive, it will return to the - Select Drives screen after the boot manager selection. If you wish to - install &os; on to more than one disk, then you can select another - disk here and repeat the slice process using + Select Drives screen after the boot manager selection. To + install &os; on to more than one disk, select another + disk and repeat the slice process using FDisk. - If you are installing &os; on a drive other than your - first, then the &os; boot manager needs to be installed on + If installing &os; on a drive other than the + first drive, the &os; boot manager needs to be installed on both drives.
Exit Select Drive
- The Tab key toggles between the last drive + Use Tab to toggle between the last drive selected, &gui.ok;, and &gui.cancel;. - Press the Tab once to toggle to the + Press Tab once to toggle to &gui.ok;, then press Enter to continue with the installation. Creating Partitions Using <application>Disklabel</application> - You must now create some partitions inside each slice that you - have just created. Remember that each partition is lettered, from + Next, create some partitions inside each slice. + Remember that each partition is lettered, from a through to h, and that partitions b, c, and - d have conventional meanings that you should adhere + d have conventional meanings that should + be adhered to. Certain applications can benefit from particular partition - schemes, especially if you are laying out partitions across more than - one disk. However, for this, your first &os; installation, you do - not need to give too much thought to how you partition the disk. It - is more important that you install &os; and start learning how to - use it. You can always re-install &os; to change your partition - scheme when you are more familiar with the operating system. - - This scheme features four partitions—one for swap space, and + schemes, especially when laying out partitions across more + than + one disk. However, for a first &os; installation, do + not give too much thought to how to partition the disk. It + is more important to install &os; and start learning how to + use it. You can always re-install &os; to change the + partition + scheme after becoming more familiar with the operating + system. + + The following scheme features four partitions: one + for swap space and three for filesystems. Partition Layout for First Disk Partition Filesystem Size Description a - / + / 1 GB This is the root filesystem. Every other filesystem will be mounted somewhere under this one. 1 GB is a - reasonable size for this filesystem. You will not be storing - too much data on it, as a regular &os; install will put - about 128 MB of data here. The remaining space is for - temporary data, and also leaves expansion space if future - versions of - &os; need more space in /. + reasonable size for this filesystem as user files + should not be stored here and + a regular &os; install will put + about 128 MB of data here. b N/A 2-3 x RAM The system's swap space is kept on the b partition. Choosing the right amount of swap space can be a bit of an - art. A good rule of thumb is that your swap + art. A good rule of thumb is that swap space should be two or three times as much as the available physical memory (RAM). - You should also have at least 64 MB of swap, so if you - have less than 32 MB of RAM in your computer then set - the swap amount to 64 MB. - - If you have more than one disk then you can put swap - space on each disk. &os; will then use each disk for + There should be at least 64 MB of swap, so if + there is + less than 32 MB of RAM in the computer, set + the swap amount to 64 MB. + If there is more than one disk, swap + space can be put on each disk. &os; will then use + each disk for swap, which effectively speeds up the act of swapping. In - this case, calculate the total amount of swap you need - (e.g., 128 MB), and then divide this by the number of - disks you have (e.g., two disks) to give the amount of swap - you should put on each disk, in this example, 64 MB of - swap per disk. + this case, calculate the total amount of swap needed + and divide this by the number of + disks to give the amount of swap + to put on each disk. e - /var + /var 512 MB to 4096 MB - The /var directory contains - files that are constantly varying; - log files, and other administrative files. Many - of these files are read-from or written-to extensively during + /var + contains + files that are constantly varying, such as + log files and other administrative files. Many + of these files are read from or written to extensively + during &os;'s day-to-day running. Putting these files on another filesystem allows &os; to optimize the access of these files without affecting other files in other directories that do not have the same access pattern. f - /usr + /usr Rest of disk (at least 8 GB) - All your other files will typically be stored in - /usr and its subdirectories. + All other files will typically be stored in + /usr and its + subdirectories.
The values above are given as example and should be used by experienced users only. Users are encouraged to use the automatic partition layout called Auto Defaults by the &os; partition editor. - If you will be installing &os; on to more than one disk then - you must also create partitions in the other slices that you - configured. The easiest way to do this is to create two partitions on + If installing &os; on to more than one disk, + create partitions in the other configured slices. + The easiest way to do this is to create two partitions on each disk, one for the swap space, and one for a filesystem. Partition Layout for Subsequent Disks Partition Filesystem Size Description b N/A See description - As already discussed, you can split swap space across + Swap space can be split across each disk. Even though the a partition is free, convention dictates that swap space stays on the b partition. e /diskn Rest of disk The rest of the disk is taken up with one big partition. This could easily be put on the a partition, instead of the e partition. However, convention says that the a partition on a slice is reserved for the filesystem that will - be the root (/) filesystem. You do not - have to follow this convention, but - sysinstall does, so following it - yourself makes the installation slightly cleaner. You can - choose to mount this filesystem anywhere; this example - suggests that you mount them as directories - /diskn, where + be the root (/) + filesystem. Following + this convention is not necessary, but + &man.sysinstall.8; uses it, so following it + makes the installation slightly cleaner. + This filesystem can be mounted anywhere; this example + mounts it as + /diskn, + where n is a number that changes for each - disk. But you can use another scheme if you prefer. + disk.
- Having chosen your partition layout you can now create it using - sysinstall. You will see this - message: + Having chosen the partition layout, create it using + &man.sysinstall.8;. Message Now, you need to create BSD partitions inside of the fdisk partition(s) just created. If you have a reasonable amount of disk space (1GB or more) and don't have any special requirements, simply use the (A)uto command to allocate space automatically. If you have more specific needs or just don't care for the layout chosen by (A)uto, press F1 for more information on manual layout. [ OK ] [ Press enter or space ] - Press Enter to start the FreeBSD partition + Press Enter to start the &os; partition editor, called Disklabel. - shows the display when you first - start Disklabel. The display is divided in - to three sections. + shows the display when + Disklabel starts. The display is + divided into three sections. - The first few lines show the name of the disk you are currently - working on, and the slice that contains the partitions you are - creating (at this point Disklabel calls - this the Partition name rather than slice name). + The first few lines show the name of the disk being + worked on and the slice that contains the partitions to + create. At this point, Disklabel + calls + this the Partition name rather than slice + name. This display also shows the amount of free space within the slice; that is, space that was set aside in the slice, but that has not yet been assigned to a partition. The middle of the display shows the partitions that have been created, the name of the filesystem that each partition contains, their size, and some options pertaining to the creation of the filesystem. The bottom third of the screen shows the keystrokes that are valid in Disklabel.
Sysinstall Disklabel Editor
Disklabel can automatically create - partitions for you and assign them default sizes. The default sizes + partitions and assign them default sizes. The default sizes are calculated with the help of an internal partition sizing algorithm - based on the disk size. Try this now, by - Pressing A. You will see a display similar to that + based on the disk size. + Press A to see a display similar to that shown in . Depending on the size of - the disk you are using, the defaults may or may not be appropriate. - This does not matter, as you do not have to accept the - defaults. + the disk, the defaults may or may not be appropriate. The default partitioning assigns - the /tmp directory its own partition instead - of being part of the / partition. This - helps avoid filling the / partition with + /tmp its own + partition instead + of being part of the / partition. This + helps avoid filling the / partition with temporary files.
Sysinstall Disklabel Editor with Auto Defaults
- If you choose to not use the default partitions and wish to - replace them with your - own, use the arrow keys to select the first partition, and press + To + replace the default partitions, + use the arrow keys to select the first partition and press D to delete it. Repeat this to delete all the suggested partitions. - To create the first partition (a, mounted as - / — root), make sure the proper disk slice + To create the first partition, a, + mounted as + /, make sure the + proper disk slice at the top of the screen is selected and press C. A dialog box - will appear prompting you for the size of the new partition (as shown - in ). You can enter the size as - the number of disk blocks you want to use, or as a + will appear, prompting for the size of the new partition, + as shown + in . The size can + be entered as + the number of disk blocks to use or as a number followed by either M for megabytes, G for gigabytes, or C for cylinders.
Free Space for Root Partition
The default size shown will create a partition that takes up the - rest of the slice. If you are using the partition sizes described - in the earlier example, then delete the existing figure using + rest of the slice. If using the partition sizes described + in the earlier example, delete the existing figure using Backspace, and then type in 512M, as shown in . Then press &gui.ok;.
Edit Root Partition Size
- Having chosen the partition's size you will then be asked whether + After choosing the partition's size, the installer will + ask whether this partition will contain a filesystem or swap space. The dialog box is shown in . This first partition will contain a filesystem, so check that FS is selected and press Enter.
Choose the Root Partition Type
- Finally, because you are creating a filesystem, you must tell - Disklabel where the filesystem is to be + Finally, tell + Disklabel where the filesystem will + be mounted. The dialog box is shown in - . The root filesystem's mount - point is /, so type /, and + . Type + /, and then press Enter.
Choose the Root Mount Point
- The display will then update to show you the newly created - partition. You should repeat this procedure for the other - partitions. When you create the swap partition, you will not be - prompted for the filesystem mount point, as swap partitions are never - mounted. When you create the final partition, - /usr, you can leave the suggested size as is, to + The display will then update to show the newly created + partition. Repeat this procedure for the other + partitions. When creating the swap partition, it will not + prompt for the filesystem mount point. When creating the + final partition, + /usr, leave the + suggested size as is to use the rest of the slice. - Your final &os; DiskLabel Editor screen will appear similar to - , although your values chosen may + The final &os; DiskLabel Editor screen will appear similar + to + , although the values + chosen may be different. Press Q to finish.
Sysinstall Disklabel Editor
Choosing What to Install Select the Distribution Set Deciding which distribution set to install will depend largely on the intended use of the system and the amount of disk space available. The predefined options range from installing the smallest possible configuration to everything. Those who are - new to &unix; and/or &os; should almost certainly select one + new to &unix; or &os; should select one of these canned options. Customizing a distribution set is typically for the more experienced user. Press F1 for more information on the distribution set options and what they contain. When finished - reviewing the help, pressing Enter will return + reviewing the help, press Enter to return to the Select Distributions Menu. - If a graphical user interface is desired then the - configuration of the X server and selection of a default + If a graphical user interface is desired, the + configuration of &xorg; and + selection of a default desktop must be done after the installation of &os;. More information regarding the installation and configuration of a - X server can be found in . + &xorg; can be found in . If compiling a custom kernel is anticipated, select an option which includes the source code. For more information on why a custom kernel should be built or how to build a custom kernel, see . - Obviously, the most versatile system is one that includes + The most versatile system is one that includes everything. If there is adequate disk space, select - All as shown in - by using the arrow keys and - press Enter. If there is a concern about disk - space consider using an option that is more suitable for the + All, as shown in + , by using the arrow keys + and + pressing Enter. If there is a concern about + disk + space, consider using an option that is more suitable for the situation. Do not fret over the perfect choice, as other distributions can be added after installation.
Choose Distributions
Installing the Ports Collection After selecting the desired distribution, an opportunity to - install the &os; Ports Collection is presented. The ports - collection is an easy and convenient way to install software. - The Ports Collection does not contain the source code necessary - to compile the software. Instead, it is a collection of files which - automates the downloading, compiling and installation + install the &os; Ports Collection is presented. The Ports + Collection is an easy and convenient way to install software + as it provides a collection of files that + automate the downloading, compiling, and installation of third-party software packages. - discusses how to use the ports - collection. + discusses how to use the Ports + Collection. The installation program does not check to see if you have adequate space. Select this option only if you have adequate hard disk space. As of &os; &rel.current;, the &os; Ports Collection takes up about &ports.size; of disk space. You can safely assume a larger value for more recent versions of &os;. User Confirmation Requested Would you like to install the FreeBSD ports collection? This will give you ready access to over &os.numports; ported software packages, at a cost of around &ports.size; of disk space when "clean" and possibly much more than that if a lot of the distribution tarballs are loaded (unless you have the extra CDs from a FreeBSD CD/DVD distribution available and can mount it on /cdrom, in which case this is far less of a problem). The Ports Collection is a very valuable resource and well worth having on your /usr partition, so it is advisable to say Yes to this option. For more information on the Ports Collection & the latest ports, visit: http://www.FreeBSD.org/ports [ Yes ] No Select &gui.yes; with the arrow keys to install the Ports Collection or &gui.no; to skip this option. Press Enter to continue. The Choose Distributions menu will redisplay.
Confirm Distributions
- If satisfied with the options, select + Once satisfied with the options, select Exit with the arrow keys, ensure that - &gui.ok; is highlighted, and pressing + &gui.ok; is highlighted, and press Enter to continue. - Choosing Your Installation Media + Choosing the Installation Media - If Installing from a CDROM or DVD, use the arrow keys to highlight - Install from a FreeBSD CD/DVD. Ensure + If installing from a CD/DVD, use the arrow keys to highlight + Install from a &os; CD/DVD. Ensure that &gui.ok; is highlighted, then press Enter to proceed with the installation. For other methods of installation, select the appropriate option and follow the instructions. Press F1 to display the Online Help for installation media. Press Enter to return to the media selection menu.
Choose Installation Media
FTP Installation Modes installation network FTP - There are three FTP installation modes you can choose from: + There are three FTP installation modes to choose from: active FTP, passive FTP, or via a HTTP proxy. FTP Active: Install from an FTP server - This option will make all FTP transfers + This option makes all FTP transfers use Active mode. This will not work through firewalls, but will often work with older FTP servers that do not support - passive mode. If your connection hangs with passive - mode (the default), try active! + passive mode. If the connection hangs with passive + mode (the default), try using active mode. FTP Passive: Install from an FTP server through a firewall FTP passive mode - This option instructs sysinstall - to Passive mode for all FTP operations. + This option instructs &man.sysinstall.8; + to use passive mode for all FTP + operations. This allows the user to pass through firewalls that do not allow incoming connections on random TCP ports. FTP via a HTTP proxy: Install from an FTP server through a http proxy FTP via a HTTP proxy - This option instructs sysinstall + This option instructs &man.sysinstall.8; to use the HTTP - protocol (like a web browser) to connect to a proxy + protocol to connect to a proxy for all FTP operations. The proxy will translate the requests and send them to the FTP server. This allows the user to pass through firewalls - that do not allow FTP at all, but offer a HTTP + that do not allow FTP, but offer a HTTP proxy. - In this case, you have to specify the proxy in + In this case, specify the proxy in addition to the FTP server. - For a proxy FTP server, you should usually give the name of the - server you really want as a part of the username, after an + For a proxy FTP server, give the name of the + server as part of the username, after an @ sign. The proxy server then fakes - the real server. For example, assuming you want to install from + the real server. For example, to install from ftp.FreeBSD.org, using the proxy FTP server foo.example.com, listening on port - 1234. - - In this case, you go to the options menu, set the FTP username - to ftp@ftp.FreeBSD.org, and the password to your - email address. As your installation media, you specify FTP (or + 1234, go to the options menu, set the FTP username + to ftp@ftp.FreeBSD.org and the password to + an + email address. As the installation media, specify FTP (or passive FTP, if the proxy supports it), and the URL ftp://foo.example.com:1234/pub/FreeBSD. - Since /pub/FreeBSD from + Since /pub/FreeBSD + from ftp.FreeBSD.org is proxied under - foo.example.com, you are able to install - from that machine (which will fetch the files - from ftp.FreeBSD.org as your - installation requests them). + foo.example.com, the proxy + will fetch the files + from ftp.FreeBSD.org as the + installer requests them. Committing to the Installation The installation can now proceed if desired. This is also the last chance for aborting the installation to prevent changes to the hard drive. User Confirmation Requested Last Chance! Are you SURE you want to continue the installation? If you're running this on a disk with data you wish to save then WE STRONGLY ENCOURAGE YOU TO MAKE PROPER BACKUPS before proceeding! We can take no responsibility for lost disk contents! [ Yes ] No Select &gui.yes; and press Enter to proceed. The installation time will vary according to the distribution chosen, installation media, and the speed of the computer. There will be a series of - messages displayed indicating the status. + messages displayed, indicating the status. The installation is complete when the following message is displayed: Message Congratulations! You now have FreeBSD installed on your system. We will now move on to the final configuration questions. For any option you do not wish to configure, simply select No. If you wish to re-enter this utility after the system is up, you may do so by typing: /usr/sbin/sysinstall. [ OK ] [ Press enter or space ] Press Enter to proceed with post-installation configurations. Selecting &gui.no; and pressing Enter will abort - the installation so no changes will be made to your system. The + the installation so no changes will be made to the system. The following message will appear: Message Installation complete with some errors. You may wish to scroll through the debugging messages on VTY1 with the scroll-lock feature. You can also choose "No" at the next prompt and go back into the installation menus to retry whichever operations have failed. [ OK ] This message is generated because nothing was installed. Pressing Enter will return to the Main Installation Menu to exit the installation. Post-installation - Configuration of various options follows the successful - installation. An option can be configured by re-entering the - configuration options before booting the new &os; - system or after installation using - sysinstall - and selecting - Configure. + Configuration of various options can be performed after a + successful installation. An option can be configured by + re-entering the + configuration menus before booting the new &os; + system or after boot using + &man.sysinstall.8; + and then selecting the + Configure menu. Network Device Configuration - If you previously configured PPP for an FTP install, this screen - will not display and can be configured later as described + If PPP was previously configured for an FTP install, this + screen + will not display and can be configured after boot as described above. For detailed information on Local Area Networks and configuring &os; as a gateway/router refer to the Advanced Networking chapter. User Confirmation Requested Would you like to configure any Ethernet or PPP network devices? [ Yes ] No To configure a network device, select &gui.yes; and press Enter. Otherwise, select &gui.no; to continue.
Selecting an Ethernet Device
Select the interface to be configured with the arrow keys and press Enter. User Confirmation Requested Do you want to try IPv6 configuration of the interface? Yes [ No ] In this private local area network, the current Internet type protocol (IPv4) was sufficient and &gui.no; was selected with the arrow keys and Enter pressed. - If you are connected to an existing IPv6 network - with an RA server, then choose + If connected to an existing IPv6 + network + with an RA server, choose &gui.yes; and press Enter. It will take several seconds to scan for RA servers. User Confirmation Requested Do you want to try DHCP configuration of the interface? Yes [ No ] - If DHCP (Dynamic Host Configuration Protocol) is not required + If Dynamic Host Configuration Protocol + DHCP) is not required, select &gui.no; with the arrow keys and press Enter. Selecting &gui.yes; will execute - dhclient, and if successful, will fill + &man.dhclient.8; and, if successful, will fill in the network configuration information automatically. Refer to for more information. The following Network Configuration screen shows the configuration of the Ethernet device for a system that will act as the gateway for a Local Area Network.
Set Network Configuration for <replaceable>ed0</replaceable>
Use Tab to select the information fields and fill in appropriate information: Host The fully-qualified hostname, such as k6-2.example.com in this case. Domain - The name of the domain that your machine is + The name of the domain that the machine is in, such as example.com for this case. IPv4 Gateway IP address of host forwarding packets to non-local - destinations. You must fill this in if the machine is a node + destinations. This must be filled in if the machine is + a node on the network. Leave this field blank if the machine is the gateway to the Internet for the network. The IPv4 Gateway is also known as the default gateway or default route. Name server - IP address of your local DNS server. There is no local + IP address of the local DNS server. There is no + local DNS server on this private local area network so the IP address of the provider's DNS server (208.163.10.2) was used. IPv4 address The IP address to be used for this interface was 192.168.0.1 Netmask The address block being used for this local area network is 192.168.0.0 - 192.168.0.255 with a netmask of 255.255.255.0. - Extra options to ifconfig + Extra options to &man.ifconfig.8; - Any interface-specific options to ifconfig - you would like to add. There were none in this case. + Any additional interface-specific options to + &man.ifconfig.8;. There were none in this case. Use Tab to select &gui.ok; when finished and press Enter. User Confirmation Requested Would you like to bring the ed0 interface up right now? [ Yes ] No Choosing &gui.yes; and pressing Enter will bring - the machine up on the network and be ready for use. However, + the machine up on the network so it is ready for use. + However, this does not accomplish much during installation, since the machine still needs to be rebooted. Configure Gateway User Confirmation Requested Do you want this machine to function as a network gateway? [ Yes ] No If the machine will be acting as the gateway for a local area - network and forwarding packets between other machines then select + network and forwarding packets between other machines, select &gui.yes; and press Enter. - If the machine is a node on a network then + If the machine is a node on a network, select &gui.no; and press Enter to continue. Configure Internet Services User Confirmation Requested Do you want to configure inetd and the network services that it provides? Yes [ No ] If &gui.no; is selected, various services - such telnetd will not be enabled. This - means that remote users will not be able to - telnet into this machine. Local users - will still be able to access remote machines with - telnet. - - These services can be enabled after installation by editing - /etc/inetd.conf with your favorite text editor. + will not be enabled. These services can be enabled after + installation by editing + /etc/inetd.conf with a text editor. See for more information. - Select &gui.yes; if you wish to + Otherwise, select &gui.yes; to configure these services during install. An additional confirmation will display: User Confirmation Requested The Internet Super Server (inetd) allows a number of simple Internet services to be enabled, including finger, ftp and telnetd. Enabling these services may increase risk of security problems by increasing the exposure of your system. With this in mind, do you wish to enable inetd? [ Yes ] No Select &gui.yes; to continue. User Confirmation Requested inetd(8) relies on its configuration file, /etc/inetd.conf, to determine which of its Internet services will be available. The default FreeBSD inetd.conf(5) leaves all services disabled by default, so they must be specifically enabled in the configuration file before they will function, even once inetd(8) is enabled. Note that services for IPv6 must be separately enabled from IPv4 services. Select [Yes] now to invoke an editor on /etc/inetd.conf, or [No] to use the current settings. [ Yes ] No - Selecting &gui.yes; will allow adding - services by deleting the # at the beginning - of a line. + Selecting &gui.yes; allows services to be enabled + by deleting the # at the beginning + of the lines representing those services.
Editing <filename>inetd.conf</filename>
- After adding the desired services, pressing Esc - will display a menu which will allow exiting and saving + Once the edits are complete, press Esc + to display a menu which will exit the editor and save the changes. Enabling SSH Login SSH sshd User Confirmation Requested Would you like to enable SSH login? Yes [ No ] Selecting &gui.yes; will enable &man.sshd.8;, the daemon - program for OpenSSH. This will - allow secure remote access to your machine. For more - information about OpenSSH see . + for OpenSSH. This + allows secure remote access to the machine. For more + information about OpenSSH, see + . Anonymous FTP FTP anonymous User Confirmation Requested Do you want to have anonymous FTP access to this machine? Yes [ No ] Deny Anonymous FTP Selecting the default &gui.no; and pressing Enter will still allow users who have accounts with passwords to use FTP to access the machine. Allow Anonymous FTP - Anyone can access your machine if you elect to allow - anonymous FTP connections. The security implications should be + Anyone can access the machine if + anonymous FTP connections are allowed. The security + implications should be considered before enabling this option. For more information - about security see . + about security, see . To allow anonymous FTP, use the arrow keys to select &gui.yes; and press Enter. An additional confirmation will display: User Confirmation Requested Anonymous FTP permits un-authenticated users to connect to the system FTP server, if FTP service is enabled. Anonymous users are restricted to a specific subset of the file system, and the default configuration provides a drop-box incoming directory to which uploads are permitted. You must separately enable both inetd(8), and enable ftpd(8) in inetd.conf(5) for FTP services to be available. If you did not do so earlier, you will have the opportunity to enable inetd(8) again later. If you want the server to be read-only you should leave the upload directory option empty and add the -r command-line option to ftpd(8) in inetd.conf(5) Do you wish to continue configuring anonymous FTP? [ Yes ] No - This message informs you that the FTP service will also + This message indicates that the FTP service will also have to be enabled in /etc/inetd.conf - if you want to allow anonymous FTP connections, see . Select &gui.yes; and press - Enter to continue; the following screen + to allow anonymous FTP connections. Select &gui.yes; and + press + Enter to continue. The following screen will display:
Default Anonymous FTP Configuration
Use Tab to select the information fields and fill in appropriate information: UID - The user ID you wish to assign to the anonymous + The user ID to assign to the anonymous FTP user. All files uploaded will be owned by this ID. Group - Which group you wish the anonymous FTP user to be - in. + Which group to place the anonymous FTP user + into. Comment String describing this user in /etc/passwd. FTP Root Directory Where files available for anonymous FTP will be kept. Upload Subdirectory Where files uploaded by anonymous FTP users will go. - The FTP root directory will be put in /var - by default. If you do not have enough room there for the - anticipated FTP needs, the /usr directory - could be used by setting the FTP root directory to - /usr/ftp. + The FTP root directory will be put in /var + by default. If there is not enough room there for the + anticipated FTP needs, use /usr instead + by setting the FTP root directory to + /usr/ftp. - When you are satisfied with the values, press + Once satisfied with the values, press Enter to continue. User Confirmation Requested Create a welcome message file for anonymous FTP users? [ Yes ] No - If you select &gui.yes; and press - Enter, an editor will automatically start - allowing you to edit the message. + If &gui.yes; is selected, press + Enter and the &man.cu.1; editor + will automatically start.
Edit the FTP Welcome Message
- This is a text editor called ee. Use the - instructions to change the message or change the message later - using a text editor of your choice. Note the file name/location + Use the + instructions to change the message. Note the file name + location at the bottom of the editor screen. Press Esc and a pop-up menu will default to a) leave editor. Press Enter to exit and continue. Press - Enter again to save changes if you made - any. + Enter again to save any changes. - Configure Network File System + Configure the Network File System - Network File System (NFS) allows sharing of files across a + The Network File System (NFS) allows + sharing of files across a network. A machine can be configured as a server, a client, or - both. Refer to for a more information. + both. Refer to for more + information. NFS Server User Confirmation Requested Do you want to configure this machine as an NFS server? Yes [ No ] - If there is no need for a Network File System server, + If there is no need for a NFS server, select &gui.no; and press Enter. If &gui.yes; is chosen, a message will - pop-up indicating that the exports file must be + pop-up indicating that /etc/exports + must be created. Message Operating as an NFS server means that you must first configure an /etc/exports file to indicate which hosts are allowed certain kinds of access to your local filesystems. Press [Enter] now to invoke an editor on /etc/exports [ OK ] Press Enter to continue. A text editor will - start allowing the exports file to be created - and edited. + start, allowing /etc/exports to be + edited.
Editing <filename>exports</filename>
- Use the instructions to add the actual exported filesystems - now or later using a text editor of your choice. Note the - file name/location at the bottom of the editor screen. + Use the instructions to add the exported filesystems. + Note the + file name location at the bottom of the editor + screen. Press Esc and a pop-up menu will default to a) leave editor. Press Enter to exit and continue. - NFS Client + <acronym>NFS</acronym> Client - The NFS client allows your machine to access NFS servers. + The NFS client allows the machine to + access NFS servers. User Confirmation Requested Do you want to configure this machine as an NFS client? Yes [ No ] With the arrow keys, select &gui.yes; or &gui.no; as appropriate and press Enter. System Console Settings There are several options available to customize the system console. User Confirmation Requested Would you like to customize your system console settings? [ Yes ] No To view and configure the options, select &gui.yes; and press Enter.
System Console Configuration Options
A commonly used option is the screen saver. Use the arrow keys to select Saver and then press Enter.
Screen Saver Options
Select the desired screen saver using the arrow keys and then press Enter. The System Console Configuration menu will redisplay. The default time interval is 300 seconds. To change the time interval, select Saver again. At the Screen Saver Options menu, select Timeout using the arrow keys and press Enter. A pop-up menu will appear:
Screen Saver Timeout
The value can be changed, then select &gui.ok; and press Enter to return to the System Console Configuration menu.
System Console Configuration Exit
- Selecting Exit and pressing - Enter will continue with the post-installation - configurations. + Select Exit and press + Enter to continue with the post-installation + configuration. Setting the Time Zone - Setting the time zone for your machine will allow it to + Setting the time zone allows the system to automatically correct for any regional time changes and perform other time zone related functions properly. The example shown is for a machine located in the Eastern - time zone of the United States. Your selections will vary according - to your geographical location. + time zone of the United States. The selections will vary + according + to the geographic location. User Confirmation Requested Would you like to set this machine's time zone now? [ Yes ] No Select &gui.yes; and press Enter to set the time zone. User Confirmation Requested Is this machine's CMOS clock set to UTC? If it is set to local time or you don't know, please choose NO here! Yes [ No ] Select &gui.yes; or &gui.no; according to how the machine's - clock is configured and press Enter. + clock is configured, then press Enter.
- Select Your Region + Select the Region
The appropriate region is selected using the arrow keys and then pressing Enter.
- Select Your Country + Select the Country
Select the appropriate country using the arrow keys and press Enter.
- Select Your Time Zone + Select the Time Zone
The appropriate time zone is selected using the arrow keys and pressing Enter. Confirmation Does the abbreviation 'EDT' look reasonable? [ Yes ] No - Confirm the abbreviation for the time zone is correct. + Confirm that the abbreviation for the time zone is + correct. If it looks okay, press Enter to continue with the post-installation configuration. Mouse Settings - This option will allow you to cut and paste text in the - console and user programs with a 3-button mouse. If using a 2-button - mouse, refer to manual page, &man.moused.8;, after installation for + This option allows cut and paste in the + console and user programs using a 3-button mouse. If using a + 2-button + mouse, refer to &man.moused.8; for details on emulating the 3-button style. This example depicts a - non-USB mouse configuration (such as a PS/2 or COM port mouse): + non-USB mouse configuration: User Confirmation Requested Does this system have a PS/2, serial, or bus mouse? [ Yes ] No - Select &gui.yes; for a PS/2, serial or bus mouse, or - &gui.no; for a USB mouse and press + Select &gui.yes; for a PS/2, serial, or bus mouse, or + &gui.no; for a USB mouse, then press Enter.
Select Mouse Protocol Type
Use the arrow keys to select Type and press Enter.
Set Mouse Protocol
The mouse used in this example is a PS/2 type, so the default - Auto was appropriate. To change protocol, + Auto is appropriate. To change the + mouse protocol, use the arrow keys to select another option. Ensure that &gui.ok; is highlighted and press Enter to exit this menu.
Configure Mouse Port
Use the arrow keys to select Port and press Enter.
Setting the Mouse Port
This system had a PS/2 mouse, so the default - PS/2 was appropriate. To change the port, + PS/2 is appropriate. To change the + port, use the arrow keys and then press Enter.
Enable the Mouse Daemon
Last, use the arrow keys to select Enable, and press Enter to enable and test the mouse daemon.
Test the Mouse Daemon
- Move the mouse around the screen and verify the cursor - shown responds properly. If it does, select + Move the mouse around the screen to verify that the cursor + responds properly. If it does, select &gui.yes; and press Enter. If - not, the mouse has not been configured correctly — select + not, the mouse has not been configured correctly. Select &gui.no; and try using different configuration options. Select Exit with the arrow keys - and press Enter to return to continue with the + and press Enter to continue with the post-installation configuration. Install Packages Packages are pre-compiled binaries and are a convenient way to install software. Installation of one package is shown for purposes of illustration. Additional packages can also be added at this - time if desired. After installation - sysinstall can be used to add additional + time if desired. After installation, + &man.sysinstall.8; can be used to add additional packages. User Confirmation Requested The FreeBSD package collection is a collection of hundreds of ready-to-run applications, from text editors to games to WEB servers and more. Would you like to browse the collection now? [ Yes ] No - Selecting &gui.yes; and pressing - Enter will be - followed by the Package Selection screens: + Select &gui.yes; and press + Enter to be presented with + the Package Selection screens:
Select Package Category
Only packages on the current installation media are available for installation at any given time. All packages available will be displayed if - All is selected or you can select a - particular category. Highlight your selection with the arrow + All is selected. Otherwise, select + a + particular category. Highlight the selection with the arrow keys and press Enter. A menu will display showing all the packages available for the selection made:
Select Packages
- The bash shell is shown selected. - Select as many as desired by highlighting the package and pressing the - Space key. A short description of each package will + The bash shell is shown as + selected. + Select as many packages as desired by highlighting the package + and pressing + Space. A short description of each package + will appear in the lower left corner of the screen. - Pressing the Tab key will toggle between the last + Press Tab to toggle between the last selected package, &gui.ok;, and &gui.cancel;. - When you have finished marking the packages for installation, - press Tab once to toggle to the &gui.ok; and press + Once finished marking the packages for installation, + press Tab once to toggle to &gui.ok; and + press Enter to return to the Package Selection menu. The left and right arrow keys will also toggle between &gui.ok; and &gui.cancel;. This method can also be used to select &gui.ok; and press Enter to return to the Package Selection menu.
Install Packages
Use the Tab and arrow keys to select [ Install ] - and press Enter. You will then need to confirm - that you want to install the packages: + and press Enter to see the installation + confirmation message:
Confirm Package Installation
- Selecting &gui.ok; and pressing Enter will start - the package installation. Installing messages will appear until + Select &gui.ok; and press Enter to start + the package installation. Installation messages will appear + until all of the installations have completed. Make note if there are any error messages. The final configuration continues after packages are - installed. If you end up not selecting any packages, and wish - to return to the final configuration, select - Install anyways. + installed. If no packages are selected, select + Install to return to the final + configuration. Add Users/Groups - You should add at least one user during the installation so - that you can use the system without being logged in as + Add at least one user during the installation so + that the system can be used without logging in as root. The root partition is generally small and running applications as root can quickly fill it. A bigger danger is noted below: User Confirmation Requested Would you like to add any initial user accounts to the system? Adding at least one account for yourself at this stage is suggested since working as the "root" user is dangerous (it is easy to do things which adversely affect the entire system). [ Yes ] No Select &gui.yes; and press Enter to continue with adding a user.
Select User
Select User with the arrow keys and press Enter.
Add User Information
The following descriptions will appear in the lower part of the screen as the items are selected with Tab to assist with entering the required information: Login ID The login name of the new user (mandatory). UID The numerical ID for this user (leave blank for automatic choice). Group The login group name for this user (leave blank for automatic choice). Password The password for this user (enter this field with care!). Full name The user's full name (comment). Member groups - The groups this user belongs to (i.e., gets access - rights for). + The groups this user belongs to. Home directory The user's home directory (leave blank for default). Login shell The user's login shell (leave blank for - default, e.g., /bin/sh). + default of /bin/sh). - The login shell was changed from /bin/sh to + In this example, the login shell was changed from + /bin/sh to /usr/local/bin/bash to use the bash shell that was previously installed as - a package. Do not try to use a shell that does not exist or you will - not be able to login. The most common shell used in the - BSD-world is the C shell, which can be indicated as + a package. Do not use a shell that does not exist or the user + will + not be able to login. The most common shell used in &os; + is the C shell, /bin/tcsh. The user was also added to the wheel group to be able to become a superuser with root privileges. - When you are satisfied, press &gui.ok; and + Once satisfied, press &gui.ok; and the User and Group Management menu will redisplay:
Exit User and Group Management
- Groups can also be added at this time if specific needs - are known. Otherwise, this may be accessed through using - sysinstall - after installation is - completed. + Groups can also be added at this time. Otherwise, this + menu may be accessed using + &man.sysinstall.8; + at a later time. - When you are finished adding users, select + When finished adding users, select Exit with the arrow keys and press Enter to continue the installation. Set the <username>root</username> Password Message Now you must set the system manager's password. This is the password you'll use to log in as "root". [ OK ] [ Press enter or space ] Press Enter to set the root password. - The password will need to be typed in twice correctly. Needless to - say, make sure you have a way of finding the password if you - forget. Notice that the password you type in is not echoed, nor + The password will need to be typed in twice correctly. + Do not forget this password. + Notice that the typed password is not echoed, nor are asterisks displayed. New password: Retype new password : The installation will continue after the password is successfully entered. Exiting Install - If you need to configure - additional network services - or any other configuration, you can do it at this point or - after installation with sysinstall. + A message will ask if + configuration is complete: User Confirmation Requested Visit the general configuration menu for a chance to set any last options? Yes [ No ] Select &gui.no; with the arrow keys and press Enter to return to the Main Installation Menu.
Exit Install
Select [X Exit Install] with the arrow - keys and press Enter. You will be asked to + keys and press Enter. The installer will + prompt to confirm exiting the installation: User Confirmation Requested Are you sure you wish to exit? The system will reboot. [ Yes ] No - Select &gui.yes;. If you are booting from the CDROM drive + Select &gui.yes;. If booting from the CDROM drive, the following message will remind you to remove the disk: Message Be sure to remove the media from the drive. [ OK ] [ Press enter or space ] The CDROM drive is locked until the machine - starts to reboot then the disk can - be removed from drive (quickly). Press &gui.ok; to reboot. + starts to reboot, then the disk can quickly + be removed from the drive. Press &gui.ok; to reboot. The system will reboot so watch for any error messages that may appear, see for more details. Tom Rhodes Contributed by Configure Additional Network Services Configuring network services can be a daunting - task for new users if they lack previous - knowledge in this area. Networking, including the Internet, - is critical to all modern operating systems including &os;; - as a result, it is very useful to have some understanding - &os;'s extensive networking capabilities. Doing this - during the installation will ensure users have some - understanding of the various services available to them. + task for users that lack previous + knowledge in this area. Since networking and the Internet + are critical to all modern operating systems, + it is useful to have some understanding of + &os;'s extensive networking capabilities. Network services are programs that accept input from - anywhere on the network. Every effort is made to make sure - these programs will not do anything harmful. - Unfortunately, programmers are not perfect and through time + anywhere on the network. Since there have been cases where bugs in network services have been - exploited by attackers to do bad things. It is important that - you only enable the network services you know that you need. If - in doubt it is best if you do not enable a network service until - you find out that you do need it. You can always enable it - later by re-running sysinstall or by - using the features provided by the - /etc/rc.conf file. + exploited by attackers, it is important to + only enable needed network services. If + in doubt, do not enable a network service until + it is needed. Services can be enabled + with &man.sysinstall.8; or by + editing + /etc/rc.conf. Selecting the Networking option will display a menu similar to the one below:
Network Configuration Upper-level
- The first option, Interfaces, was - previously covered during the , - thus this option can safely be ignored. + The first option, Interfaces, + is covered in . Selecting the AMD option adds - support for the BSD automatic mount utility. - This is usually used in conjunction with the - NFS protocol (see below) - for automatically mounting remote file systems. - No special configuration is required here. - - Next in line is the AMD Flags - option. When selected, a menu will pop up for you - to enter specific AMD flags. + support for &man.amd.8;. + This is usually used in conjunction with + NFS + for automatically mounting remote filesystems. + + Next is the AMD Flags + option. When selected, a menu will pop up where + specific AMD flags can be entered. The menu already contains a set of default options: -a /.amd_mnt -l syslog /host /etc/amd.map /net /etc/amd.map - The option sets the default mount + sets the default mount location which is specified here as - /.amd_mnt. The - option specifies the default log file; - however, when syslogd is used all log - activity will be sent to the system log daemon. The - /host directory is used + /.amd_mnt. + specifies the default log; + however, when &man.syslogd.8; is used, all log + activity will be sent to the system log daemon. + /host is used to mount an exported file system from a remote host, while /net - directory is used to mount an exported file system from an - IP address. The - /etc/amd.map file defines the default - options for AMD exports. + is used to mount an exported filesystem from an + IP address. The default + options for AMD exports are defined in + /etc/amd.map. FTP anonymous The Anon FTP option permits anonymous FTP connections. Select this option to make this machine an anonymous FTP server. Be aware of the security risks involved with this option. Another menu will be displayed to explain the security risks and configuration in depth. - The Gateway configuration menu will set - the machine up to be a gateway as explained previously. This - can be used to unset the Gateway option if - you accidentally selected it during the installation process. + The Gateway menu will configure + the machine to be a gateway. This menu + can also be used to unset the + Gateway option if + it was accidentally selected during installation. The Inetd option can be used to configure - or completely disable the &man.inetd.8; daemon as discussed - above. + or completely disable &man.inetd.8;. The Mail option is used to configure the - system's default MTA or Mail Transfer Agent. + system's default Mail Transfer Agent (MTA). Selecting this option will bring up the following menu:
Select a Default MTA
- Here you are offered a choice as to which + This menu offers a choice as to which MTA to install - and set as the default. An MTA is nothing - more than a mail server which delivers email to users on the + and set as the default. An MTA is + a mail server which delivers email to users on the system or the Internet. - Selecting Sendmail will install - the popular sendmail server which - is the &os; default. The Sendmail local - option will set sendmail to be the default + Select Sendmail to install + Sendmail as the default + MTA. Select + Sendmail local + to set Sendmail as the + default MTA, but disable its ability to receive - incoming email from the Internet. The other options here, + incoming email from the Internet. The other options, Postfix and - Exim act similar to - Sendmail. They both deliver - email; however, some users prefer these alternatives to the - sendmail - MTA. - - After selecting an MTA, or choosing - not to select an MTA, the network configuration menu will appear - with the next option being NFS client. - - The NFS client option will - configure the system to communicate with a server via - NFS. An NFS server - makes file systems available to other machines on the - network via the NFS protocol. If this is - a stand-alone machine, this option can remain unselected. - The system may require more configuration later; see + Exim, provide + alternatives to + Sendmail. + + The next menu after the MTA menu is + NFS client. This menu is used to + configure the system to communicate with a + NFS server which in turn is used to + make filesystems available to other machines on the + network over the NFS protocol. + See for more information about client and server configuration. Below that option is the NFS server - option, permitting you to set the system up as an + option, for setting the system up as an NFS server. This adds the required - information to start up the RPC remote - procedure call services. RPC is used to + information to start up the Remote Procedure + Call RPC + services. RPC is used to coordinate connections between hosts and programs. Next in line is the Ntpdate option, which deals with time synchronization. When selected, a menu like the one below shows up:
Ntpdate Configuration
- From this menu, select the server which is the closest - to your location. Selecting a close one will make the time - synchronization more accurate as a server further from your - location may have more connection latency. + From this menu, select the server which is geographically + closest. + This will make the time + synchronization more accurate as a farther server + may have more connection latency. The next option is the PCNFSD selection. This option will install the net/pcnfsd package from the Ports Collection. This is a useful utility which provides NFS authentication services for systems which are unable to provide their own, such as Microsoft's &ms-dos; operating system. - Now you must scroll down a bit to see the other + Now, scroll down a bit to see the other options:
Network Configuration Lower-level
- The &man.rpcbind.8;, &man.rpc.statd.8;, and - &man.rpc.lockd.8; utilities are all used for Remote Procedure - Calls (RPC). - The rpcbind utility manages communication - between NFS servers and clients, and is + RPC. + communication + between NFS servers and clients is managed + by &man.rpcbind.8; which is required for NFS servers to operate - correctly. The rpc.statd daemon interacts - with the rpc.statd daemon on other hosts to - provide status monitoring. The reported status is usually held - in the /var/db/statd.status file. The - next option listed here is the rpc.lockd - option, which, when selected, will provide file locking + correctly. Status monitoring is provided by + &man.rpc.statd.8; and the reported status is usually held + in /var/db/statd.status. The + next option is for &man.rpc.lockd.8; + which provides file locking services. This is usually used with - rpc.statd to monitor what hosts are + &man.rpc.statd.8; to monitor which hosts are requesting locks and how frequently they request them. - While these last two options are marvelous for debugging, they + While these last two options are useful for debugging, they are not required for NFS servers and clients to operate correctly. - As you progress down the list the next item here is - Routed, which is the routing daemon. The - &man.routed.8; utility manages network routing tables, + The next menu, + Routed, configures the routing + daemon. + &man.routed.8;, manages network routing tables, discovers multicast routers, and supplies a copy of the routing tables to any physically connected host on the network upon request. This is mainly used for machines which act as a - gateway for the local network. When selected, a menu will be - presented requesting the default location of the utility. - The default location is already defined for you and can be - selected with the Enter key. You will then - be presented with yet another menu, this time asking for the - flags you wish to pass on to routed. The - default is and it should already appear + gateway for the local network. If selected, a menu will + request the default location of the utility. + To accept the default location, + press Enter. Yet + another menu will ask for the + flags to pass to &man.routed.8;. The + default of should appear on the screen. - Next in line is the Rwhod option which, - when selected, will start the &man.rwhod.8; daemon - during system initialization. The rwhod + The next menu, Rwhod, + starts &man.rwhod.8; + during system initialization. This utility broadcasts system messages across the network periodically, or collects them when in consumer - mode. More information can be found in the &man.ruptime.1; and - &man.rwho.1; manual pages. - - The next to the last option in the list is for the - &man.sshd.8; daemon. This is the secure shell server for - OpenSSH and it is highly recommended - over the standard telnet and - FTP servers. The sshd - server is used to create a secure connection from one host to - another by using encrypted connections. - - Finally there is the TCP Extensions - option. This enables the TCP Extensions + mode. More information can be found in &man.ruptime.1; and + &man.rwho.1;. + + The next to last option in the list is for + &man.sshd.8;, the secure shell server for + OpenSSH. It is highly recommended + over the standard &man.telnetd.8; and + &man.ftpd.8; servers as it + is used to create a secure, encrypted connection from one host + to + another. + + The final option is TCP + Extensions which are defined in RFC 1323 and RFC 1644. While on many hosts this can speed up connections, it can also cause some connections to be dropped. It is not recommended for servers, but may be beneficial for stand alone machines. - Now that you have configured the network services, you can + Once the network services are configured, scroll up to the very top item which is X Exit and continue on to the next configuration item or simply exit - sysinstall in selecting + &man.sysinstall.8; by selecting X Exit twice then [X Exit Install]. &os; Bootup &os;/&arch.i386; Bootup - If everything went well, you will see messages scroll - off the screen and you will arrive at a login prompt. You can view - the content of the messages by pressing Scroll-Lock - and using PgUp and PgDn. - Pressing Scroll-Lock again will return + If everything went well, messages will scroll along + the screen and a login prompt will appear. To view + these messages, press + Scroll-Lock + then use PgUp and PgDn. + Press Scroll-Lock again to return to the prompt. - The entire message may not display (buffer limitation) but - it can be viewed from the command line after logging in by typing - dmesg at the prompt. + All of the messages may not display due to buffer + limitations, but + they can be read after logging using + &man.dmesg.8;. - Login using the username/password you set during installation - (rpratt, in this example). Avoid logging in as + Login using the username and password which were set + during installation. Avoid logging in as root except when necessary. Typical boot messages (version information omitted): Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. Timecounter "i8254" frequency 1193182 Hz CPU: AMD-K6(tm) 3D processor (300.68-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x580 Stepping = 0 Features=0x8001bf<FPU,VME,DE,PSE,TSC,MSR,MCE,CX8,MMX> AMD Features=0x80000800<SYSCALL,3DNow!> real memory = 268435456 (262144K bytes) config> di sn0 config> di lnc0 config> di le0 config> di ie0 config> di fe0 config> di cs0 config> di bt0 config> di aic0 config> di aha0 config> di adv0 config> q avail memory = 256311296 (250304K bytes) Preloaded elf kernel "kernel" at 0xc0491000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc049109c. md0: Malloc disk Using $PIR table, 4 entries at 0xc00fde60 npx0: <math processor> on motherboard npx0: INT 16 interface pcib0: <Host to PCI bridge> on motherboard pci0: <PCI bus> on pcib0 pcib1: <VIA 82C598MVP (Apollo MVP3) PCI-PCI (AGP) bridge> at device 1.0 on pci0 pci1: <PCI bus> on pcib1 pci1: <Matrox MGA G200 AGP graphics accelerator> at 0.0 irq 11 isab0: <VIA 82C586 PCI-ISA bridge> at device 7.0 on pci0 isa0: <ISA bus> on isab0 atapci0: <VIA 82C586 ATA33 controller> port 0xe000-0xe00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: <VIA 83C572 USB controller> port 0xe400-0xe41f irq 10 at device 7.2 on pci0 usb0: <VIA 83C572 USB controller> on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered chip1: <VIA 82C586B ACPI interface> at device 7.3 on pci0 ed0: <NE2000 PCI Ethernet (RealTek 8029)> port 0xe800-0xe81f irq 9 at device 10.0 on pci0 ed0: address 52:54:05:de:73:1b, type NE2000 (16 bit) isa0: too many dependant configs (8) isa0: unexpected small tag 14 fdc0: <NEC 72065B or clone> at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: <keyboard controller (i8042)> at port 0x60-0x64 on isa0 atkbd0: <AT Keyboard> flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: <PS/2 Mouse> irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 sc0: <System console> at flags 0x1 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc0: <Parallel port> at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/15 bytes threshold ppbus0: IEEE1284 device found /NIBBLE Probing for PnP devices on ppbus0: plip0: <PLIP network interface> on ppbus0 lpt0: <Printer> on ppbus0 lpt0: Interrupt-driven port ppi0: <Parallel I/O> on ppbus0 ad0: 8063MB <IBM-DHEA-38451> [16383/16/63] at ata0-master using UDMA33 ad2: 8063MB <IBM-DHEA-38451> [16383/16/63] at ata1-master using UDMA33 acd0: CDROM <DELTA OTC-H101/ST3 F/W by OIPD> at ata0-slave using PIO4 Mounting root from ufs:/dev/ad0s1a swapon: adding /dev/ad0s1b as swap device Automatic boot in progress... /dev/ad0s1a: FILESYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s1a: clean, 48752 free (552 frags, 6025 blocks, 0.9% fragmentation) /dev/ad0s1f: FILESYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s1f: clean, 128997 free (21 frags, 16122 blocks, 0.0% fragmentation) /dev/ad0s1g: FILESYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s1g: clean, 3036299 free (43175 frags, 374073 blocks, 1.3% fragmentation) /dev/ad0s1e: filesystem CLEAN; SKIPPING CHECKS /dev/ad0s1e: clean, 128193 free (17 frags, 16022 blocks, 0.0% fragmentation) Doing initial network setup: hostname. ed0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 inet6 fe80::5054::5ff::fede:731b%ed0 prefixlen 64 tentative scopeid 0x1 ether 52:54:05:de:73:1b lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x8 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 Additional routing options: IP gateway=YES TCP keepalive=YES routing daemons:. additional daemons: syslogd. Doing additional network setup:. Starting final network daemons: creating ssh RSA host key Generating public/private rsa1 key pair. Your identification has been saved in /etc/ssh/ssh_host_key. Your public key has been saved in /etc/ssh/ssh_host_key.pub. The key fingerprint is: cd:76:89:16:69:0e:d0:6e:f8:66:d0:07:26:3c:7e:2d root@k6-2.example.com creating ssh DSA host key Generating public/private dsa key pair. Your identification has been saved in /etc/ssh/ssh_host_dsa_key. Your public key has been saved in /etc/ssh/ssh_host_dsa_key.pub. The key fingerprint is: f9:a1:a9:47:c4:ad:f9:8d:52:b8:b8:ff:8c:ad:2d:e6 root@k6-2.example.com. setting ELF ldconfig path: /usr/lib /usr/lib/compat /usr/X11R6/lib /usr/local/lib a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout /usr/X11R6/lib/aout starting standard daemons: inetd cron sshd usbd sendmail. Initial rc.i386 initialization:. rc.i386 configuring syscons: blank_time screensaver moused. Additional ABI support: linux. Local package initialization:. Additional TCP options:. FreeBSD/i386 (k6-2.example.com) (ttyv0) login: rpratt Password: Generating the RSA and DSA keys may take some time on slower machines. This happens only on the initial boot-up of a new installation. Subsequent boots will be faster. - If the X server has been configured and a Default Desktop + If &xorg; has been configured + and a default desktop chosen, it can be started by typing startx at the command line. &os; Shutdown It is important to properly shutdown the operating - system. Do not just turn off power. First, become a superuser by - typing su at the command line and entering the + system. Do not just turn off the power. First, become the + superuser using + &man.su.1; and entering the root password. This will work only if the user - is a member of the wheel group. - Otherwise, login as root and use + is a member of wheel. + Otherwise, login as root. To shutdown + the system, type shutdown -h now. The operating system has halted. Please press any key to reboot. It is safe to turn off the power after the shutdown command has been issued and the message Please press any key to reboot appears. If any key is pressed instead of turning off the power switch, the system will reboot. - You could also use the + The Ctrl Alt Del - key combination to reboot the system, however this is not recommended - during normal operation. + key combination can also be used to reboot the system; + however, this is not recommended. Troubleshooting installation troubleshooting - The following section covers basic installation troubleshooting, - such as common problems people have reported. There are also a few + This section covers basic installation troubleshooting of + common problems. There are also a few questions and answers for people wishing to dual-boot &os; with - &ms-dos; or &windows;. + &windows;. - What to Do If Something Goes Wrong + If Something Goes Wrong Due to various limitations of the PC architecture, it is - impossible for probing to be 100% reliable, however, there are a - few things you can do if it fails. + impossible for device probing to be 100% reliable. However, + there are a + few things to try if it fails. Check the Hardware Notes - document for your version of &os; to make sure your + document for the version of &os; to make sure the hardware is supported. - If your hardware is supported and you still experience - lock-ups or other problems, you will need to build a custom kernel. This will - allow you to add in support for devices which are not present in the - GENERIC kernel. The kernel on the boot disks - is configured assuming that most hardware devices are in their - factory default configuration in terms of IRQs, IO addresses, and - DMA channels. If your hardware has been reconfigured, you will most - likely need to edit the kernel configuration and recompile to tell + If the hardware is supported but still experiences + lock-ups or other problems, build a custom kernel + to add in support for devices which are not present in the + GENERIC kernel. The default kernel + assumes that most hardware devices are in their + factory default configuration in terms of IRQs, I/O addresses, + and + DMA channels. If the hardware has been reconfigured, + create a custom kernel configuration file and recompile to + tell &os; where to find things. - It is also possible that a probe for a device not present will + It is also possible that a probe for a device not present + will cause a later probe for another device that is present to fail. In that case, the probes for the conflicting driver(s) should be disabled. Some installation problems can be avoided or alleviated by updating the firmware on various hardware components, most notably - the motherboard. The motherboard firmware may also be referred to - as BIOS and most of the motherboard or computer - manufactures have a website where the upgrades and upgrade + the motherboard + BIOS. Most motherboard and computer + manufacturers have a website where upgrade information may be located. Most manufacturers strongly advise against upgrading the motherboard BIOS unless there is a good reason - for doing so, which - could possibly be a critical update of sorts. The upgrade process + for doing so, such as + a critical update. The upgrade process can go wrong, causing permanent damage to the BIOS chip. - Using &ms-dos; and &windows; File Systems + Using &windows; Filesystems At this time, &os; does not support file systems compressed with the Double Space™ application. Therefore the file system will need to be uncompressed before &os; can access the data. This can be done by running the Compression Agent located in the Start> Programs > System Tools menu. &os; can support &ms-dos; file systems (sometimes called FAT file systems). The &man.mount.msdosfs.8; command grafts such file systems onto the existing directory hierarchy, allowing the file system's contents to be accessed. The &man.mount.msdosfs.8; program is not usually invoked directly; instead, it is called by the system through a line - in /etc/fstab or by a call to the &man.mount.8; - utility with the appropriate parameters. + in /etc/fstab or by using + &man.mount.8; + with the appropriate parameters. A typical line in /etc/fstab is: /dev/ad0sN /dos msdosfs rw 0 0 - The /dos directory must already + /dos must + already exist for this to work. For details about the format of /etc/fstab, see &man.fstab.5;. - A typical call to &man.mount.8; for a &ms-dos; file system + A typical call to &man.mount.8; for a FAT filesystem looks like: &prompt.root; mount -t msdosfs /dev/ad0s1 /mnt - In this example, the &ms-dos; file system is located on the first - partition of the primary hard disk. Your situation may be different, - check the output from the dmesg, and - mount commands. They should produce enough + In this example, the FAT filesystem is located on the + first + partition of the primary hard disk. The + output from &man.dmesg.8; and + &man.mount.8; should produce enough information to give an idea of the partition layout. - &os; may number disk slices (that is, &ms-dos; partitions) + &os; may number FAT partitions differently than other operating systems. In particular, extended - &ms-dos; partitions are usually given higher slice numbers than - primary &ms-dos; partitions. The &man.fdisk.8; utility can help + partitions are usually given higher slice numbers than + primary partitions. Use &man.fdisk.8; to help determine which slices belong to &os; and which belong to other operating systems. NTFS partitions can also be mounted in a similar manner - using the &man.mount.ntfs.8; command. + using &man.mount.ntfs.8;. Troubleshooting Questions and Answers - My system hangs while probing hardware during boot, - or it behaves strangely during install, or the floppy - drive is not probed. + My system hangs while probing hardware during boot + or it behaves strangely during install. &os; makes extensive use of the system - ACPI service on the i386, amd64 and ia64 platforms to + ACPI service on the i386, amd64, and ia64 platforms to aid in system configuration if it is detected during - boot. Unfortunately, some bugs still exist in both the - ACPI driver and within system motherboards and BIOS. + boot. Unfortunately, some bugs still exist in the + ACPI driver and various system motherboards. The use of ACPI can be disabled by setting - the hint.acpi.0.disabled hint in the + hint.acpi.0.disabled in the third stage boot loader: set hint.acpi.0.disabled="1" This is reset each time the system is booted, so it is necessary to - add hint.acpi.0.disabled="1" to the - file - /boot/loader.conf. More + add hint.acpi.0.disabled="1" to + /boot/loader.conf to make this + change permanent. More information about the boot loader can be found in . - I go to boot from the hard disk for the first time - after installing &os;, the kernel loads and probes my + When booting from the hard disk for the first time + after installing &os;, the kernel loads and probes hardware, but stops with messages like: changing root device to ad1s1a panic: cannot mount root - What is wrong? What can I do? - - What is this - bios_drive:interface(unit,partition)kernel_name - thing that is displayed with the boot help? + What is wrong? - There is a longstanding problem in the case where + This can occur when the boot disk is not the first disk in the system. The BIOS uses a different numbering scheme to &os;, and working out which numbers correspond to which is difficult to get right. - In the case where the boot disk is not the first - disk in the system, &os; can need some help finding it. - There are two common situations here, and in both of - these cases, you need to tell &os; where the root - filesystem is. You do this by specifying the BIOS disk - number, the disk type and the &os; disk number for that + If this occurs, + tell &os; where the root + filesystem is by specifying the BIOS disk + number, the disk type, and the &os; disk number for that type. - The first situation is where you have two IDE disks, + Consider two IDE disks, each configured as the master on their respective IDE - busses, and wish to boot &os; from the second disk. The + bus, where &os; should be booted from the second disk. + The BIOS sees these as disk 0 and disk 1, while &os; sees them as ad0 and ad2. - &os; is on BIOS disk 1, of type - ad and the &os; disk number is 2, so - you would say: + If &os; is on BIOS disk 1, of type + ad and the &os; disk number is 2, + this is the correct value: 1:ad(2,a)kernel - Note that if you have a slave on the primary bus, - the above is not necessary (and is effectively - wrong). + Note that if there is a slave on the primary bus, + the above is not necessary and is effectively + wrong. The second situation involves booting from a SCSI - disk when you have one or more IDE disks in the system. + disk when there are one or more IDE disks in the system. In this case, the &os; disk number is lower than the - BIOS disk number. If you have two IDE disks as well as - the SCSI disk, the SCSI disk is BIOS disk 2, - type da and &os; disk number 0, so - you would say: + BIOS disk number. For two IDE disks and a + SCSI disk, where the SCSI disk is BIOS disk 2, + type da, and &os; disk number 0, the + correct value is: 2:da(0,a)kernel - To tell &os; that you want to boot from BIOS disk 2, - which is the first SCSI disk in the system. If you only - had one IDE disk, you would use 1: + This tells &os; to boot from BIOS disk 2, + which is the first SCSI disk in the system. If there + is only IDE disk, use 1: instead. - Once you have determined the correct values to use, - you can put the command exactly as you would have typed - it in the /boot.config file using a - standard text editor. Unless instructed otherwise, &os; + Once the correct value to use is determined, + put the command + in /boot.config using a + text editor. Unless instructed otherwise, &os; will use the contents of this file as the default response to the boot: prompt. - I go to boot from the hard disk for the first time - after installing &os;, but the Boot Manager prompt just - prints F? at the boot menu each time - but the boot will not go any further. + When booting from the hard disk for the first time + after installing &os;, the Boot Manager prompt just + prints F? at the boot menu and + the boot will not go any further. The hard disk geometry was set incorrectly in the - partition editor when you installed &os;. Go back into + partition editor when &os; was installed. Go back into the partition editor and specify the actual geometry of - your hard disk. You must reinstall &os; again from the + the hard disk. &os; must be reinstalled again from the beginning with the correct geometry. - If you are failing entirely in figuring out the - correct geometry for your machine, here is a tip: Install - a small &ms-dos; partition at the beginning of the disk and - install &os; after that. The install program will see - the &ms-dos; partition and try to infer the correct geometry - from it, which usually works. - - The following tip is no longer recommended, but is - left here for reference: - -
- If you are setting up a truly dedicated &os; - server or workstation where you do not care for - (future) compatibility with &ms-dos;, Linux or another - operating system, you also have got the option to use - the entire disk (A in the partition - editor), selecting the non-standard option where &os; occupies - the entire disk from the very first to the very last - sector. This will leave all geometry considerations - aside, but is somewhat limiting unless you're never - going to run anything other than &os; on a - disk. -
+ For a dedicated &os; system that does not need + future compatibility with another operating system, + use the entire disk by selecting + A in the installer's + partition editor. - The system finds my &man.ed.4; network card, but I - keep getting device timeout errors. + The system finds the &man.ed.4; network card but + continuously displays device timeout errors. - Your card is probably on a different IRQ from what + The card is probably on a different IRQ from what is specified in - the /boot/device.hints file. The - &man.ed.4; driver does not use the soft - configuration by default (values entered using EZSETUP in - &ms-dos;), - but it will use the software configuration if you - specify -1 in the hints for the + /boot/device.hints. The + &man.ed.4; driver does not use software + configuration by default, + but it will if + -1 is specified in the hints for the interface. - Either move the jumper on the card to a hard - configuration setting (altering the kernel settings if - necessary), or specify the IRQ as -1 + Either move the jumper on the card to the + configuration setting or specify the IRQ as + -1 by setting the hint hint.ed.0.irq="-1". - This will tell the kernel to use the soft + This tells the kernel to use the software configuration. - Another possibility is that your card is at IRQ 9, + Another possibility is that the card is at IRQ 9, which is shared by IRQ 2 and frequently a cause of - problems (especially when you have a VGA card using IRQ - 2!). You should not use IRQ 2 or 9 if at all + problems, especially if a VGA card is using IRQ + 2. Do not use IRQ 2 or 9 if at all possible. color contrast - When sysinstall is used - in an X11 terminal, the yellow font is difficult to read + When &man.sysinstall.8; is used + in an &xorg; terminal, the + yellow font is difficult to read against the light gray background. Is there a way to provide higher contrast for this application? - If you already have X11 installed and the default - colors chosen by sysinstall - make text illegible while using &man.xterm.1; or &man.rxvt.1;, - add the following to your ~/.Xdefaults to + If the default + colors chosen by &man.sysinstall.8; + make text illegible while using x11/xterm or x11/rxvt, + add the following to ~/.Xdefaults + to get a darker background gray: XTerm*color7: #c0c0c0 Valentino Vaschetto Contributed by Marc Fonvieille Updated by Advanced Installation Guide This section describes how to install &os; in exceptional cases. Installing &os; on a System Without a Monitor or Keyboard installation headless (serial console) serial console This type of installation is called a headless - install, because the machine that you are trying to install - &os; on either does not have a monitor attached to it, or does not - even have a VGA output. How is this possible you ask? Using a - serial console. A serial console is basically using another - machine to act as the main display and keyboard for a - system. To do this, just follow the steps to create - an installation USB memstick, explained in or download the correct - installation ISO image, see because the machine to be installed + does not have either an attached monitor or a + VGA output. This type of installation is possible using a + serial console, another + machine which acts as the main display and keyboard. + To do this, follow the steps to create + an installation USB stick, explained in , or download the correct + installation ISO image as described in . - To modify these media to boot into a serial console, follow - these steps (If you want to use a CDROM you can skip the first + To modify the installation media to boot into a serial + console, follow + these steps. If using a CD/DVD media, skip the first step): Enabling the Installation USB Stick to Boot into a Serial Console - mount + &man.mount.8; - If you were to boot into the USB stick that you just - made, &os; would boot into its normal install mode. We - want &os; to boot into a serial console for our - install. To do this, you have to mount the - USB disk onto your &os; - system using the &man.mount.8; command. + By default, booting into the USB stick + boots into the installer. + To instead boot into a serial console, mount the + USB disk onto a &os; + system using &man.mount.8;: &prompt.root; mount /dev/da0a /mnt - Adapt the device node and the mount point to your + Adapt the device node and the mount point to the situation. - Now that you have the stick mounted, you must set - the USB stick to boot into a serial console. You have - to add to the loader.conf file of - the USB stick file system a line setting the serial - console as the system console: + Once the USB stick is mounted, set + it to boot into a serial console. + Add this line to /boot/loader.conf + on the USB stick: &prompt.root; echo 'console="comconsole"' >> /mnt/boot/loader.conf - Now that you have your USB stick configured correctly, - you must unmount the disk using the &man.umount.8; - command: + Now that the USB is stick configured correctly, + unmount the disk using &man.umount.8;: &prompt.root; umount /mnt - Now you can unplug the USB stick and jump directly + Now, unplug the USB stick and jump directly to the third step of this procedure. - Enabling the Installation CD to Boot into a + <title>Enabling the Installation CD/DVD to Boot into a Serial Console - mount + &man.mount.8; - If you were to boot into the CD that you just - made from the installation ISO image (see ), &os; would boot into its - normal install mode. We want &os; to boot into a serial - console for our install. To do this, you have to - extract, modify and regenerate the ISO image before - burning it on a CD-R media. - - From the &os; system where is saved the installation - ISO image, for example - &os;-&rel.current;-RELEASE-i386-disc1.iso, - use the &man.tar.1; utility to extract all the files: + By default, when booting into the installation + CD/DVD, &os; boots into its + normal install mode. To instead boot into a serial + console, + extract, modify, and regenerate the ISO image before + burning it to the CD/DVD media. + + From the &os; system with the saved installation + ISO image, + use &man.tar.1; to extract all the files: &prompt.root; mkdir /path/to/headless-iso &prompt.root; tar -C /path/to/headless-iso -pxvf &os;-&rel.current;-RELEASE-i386-disc1.iso - Now you must set the installation media to boot into a - serial console. You have to add to the - loader.conf file from the extracted - ISO image a line setting the serial console as the - system console: + Next, set the installation media to boot into a + serial console. Add this line to the + /boot/loader.conf of the extracted + ISO image: &prompt.root; echo 'console="comconsole"' >> /path/to/headless-iso/boot/loader.conf - Then we can create a new ISO image from the modified - tree. The &man.mkisofs.8; tool from the sysutils/cdrtools port is - used: + Then, create a new ISO image from the modified + tree. This example uses &man.mkisofs.8; from the + sysutils/cdrtools + package or port: &prompt.root; mkisofs -v -b boot/cdboot -no-emul-boot -r -J -V "Headless_install" \ - -o Headless-&os;-&rel.current;-RELEASE-i386-disc1.iso /path/to/headless-iso + -o Headless-&os;-&rel2.current;-RELEASE-i386-disc1.iso/path/to/headless-iso - Now that you have your ISO image configured correctly, - you can burn it on a CD-R with your favorite burning + Now that the ISO image is configured correctly, + burn it to a CD/DVD media using a burning application. - Connecting Your Null-modem Cable + Connecting the Null-modem Cable null-modem cable - You now need to connect a - null-modem cable between - the two machines. Just connect the cable to the serial - ports of the 2 machines. A normal serial cable - will not work here, you need a null-modem - cable because it has some of the wires inside crossed - over. + Connect a + null-modem cable + to the serial + ports of the two machines. A normal serial + cable will not work. A null-modem + cable is required. Booting Up for the Install It is now time to go ahead and start the install. Plug in - the USB memstick on - the machine you are doing the headless install - on, and power on the machine. If you are using a - prepared CDROM, power on the machine and insert the disk - to boot on. + the USB stick or insert the CD/DVD media in + the headless install machine + and power it on. - Connecting to Your Headless Machine + Connecting to the Headless Machine - cu + &man.cu.1; - Now you have to connect to that machine with + Next, connect to that machine with &man.cu.1;: &prompt.root; cu -l /dev/cuau0 - That's it! You should now be able to control the headless machine - through your cu session. It will load the kernel - and then it will come up - with a selection of what kind of terminal to use. Select the - &os; color console and proceed with your install! + The headless machine can now be controlled + using &man.cu.1;. It will load the kernel + and then dispaly + a selection of which type of terminal to use. Select the + &os; color console and proceed with the installation. - Preparing Your Own Installation Media + Preparing Custom Installation Media - - To prevent repetition, &os; disc in this context - means a &os; CDROM or DVD that you have purchased or produced - yourself. - - - There may be some situations in which you need to create your own - &os; installation media and/or source. This might be physical media, - such as a tape, or a source that sysinstall - can use to retrieve the files, such as a local FTP site, or an &ms-dos; - partition. - - For example: + Some situations may require a customized + &os; installation media and/or source. This might be physical + media + or a source that &man.sysinstall.8; + can use to retrieve the installation files. Some example + situations include: - You have many machines connected to your local network, and one - &os; disc. You want to create a local FTP site using the - contents of the &os; disc, and then have your machines use this - local FTP site instead of needing to connect to the Internet. + A local network with many machines has a private + FTP server hosting the + &os; installation files which the machines should + use for installation. - You have a &os; disc, and &os; does not recognize your - CD/DVD drive, but &ms-dos; / &windows; does. You want to copy the - &os; installation files to a &ms-dos; partition on the same + &os; does not recognize the + CD/DVD drive but &windows; does. In this case, copy the + &os; installation files to a &windows; partition on the same computer, and then install &os; using those files. - The computer you want to install on does not have a CD/DVD - drive or a network card, but you can connect a - Laplink-style serial or parallel cable to a computer + The computer to install does not have a CD/DVD + drive or a network card, but can be connected using a + null-printer cable to a computer that does. - You want to create a tape that can be used to install + A tape will be be used to install &os;. - Creating an Installation CDROM + Creating an Installation ISO - As part of each release, the &os; project makes available at - least two CDROM images (ISO images) per supported + As part of each release, the &os; Project provides ISO + images for each supported architecture. These images can be written - (burned) to CDs if you have a CD writer, and then used - to install &os;. If you have a CD writer, and bandwidth is cheap, - then this is the easiest way to install &os;. + (burned) to CD or DVD media using a burning + application, and then used + to install &os;. If a CD/DVD writer is available, + this is the easiest way to install &os;. Download the Correct ISO Images The ISO images for each release can be downloaded from ftp://ftp.FreeBSD.org/pub/FreeBSD/ISO-IMAGES-arch/version or the closest mirror. - Substitute arch and + or the closest mirror. Substitute + arch and version as appropriate. - That directory will normally contain the following images: + An image directory normally contains the following + images: &os; ISO Image Names and Meanings Filename Contents &os;-version-RELEASE-arch-bootonly.iso - This CD image allows you to start the installation + This CD image starts the installation process by booting from a CD-ROM drive but it does not contain the support for installing &os; from the CD - itself. You would need to perform a network based install - (e.g. from an FTP server) after booting from this CD. + itself. Perform a network based install, such as + from an FTP server, after booting from this + CD. &os;-version-RELEASE-arch-dvd1.iso.gz This DVD image contains everything necessary to install the base &os; operating system, a collection of pre-built packages, and the documentation. It also supports booting into a livefs based rescue mode. &os;-version-RELEASE-arch-memstick.img This image can be written to an USB memory stick - and used to do an install on machines capable of booting - off USB drives. It also supports booting into a - livefs based rescue mode. The - documentation packages are provided but no other - packages. + in order to install machines capable of booting + from USB drives. It also supports booting into a + livefs based rescue mode. The only + included package is the documentation + package. &os;-version-RELEASE-arch-disc1.iso This CD image contains the base &os; operating - system and the documentation packages but no other + system and the documentation package but no other packages. &os;-version-RELEASE-arch-disc2.iso A CD image with as many third-party packages as would fit on the disc. This image is not available for &os; 9.X. &os;-version-RELEASE-arch-disc3.iso Another CD image with as many third-party packages as would fit on the disc. This image is not available for &os; 9.X. &os;-version-RELEASE-arch-livefs.iso This CD image contains support for booting into a livefs based rescue mode but does not support doing an install from the CD itself.
- You must download one of either - the bootonly ISO image, - or the image of disc1. Do not download - both of them, since the disc1 image + When performing a CD installation, download either + the bootonly ISO image + or disc1. Do not download + both, since disc1 contains everything that the bootonly ISO image contains. - Use the bootonly ISO if Internet - access is cheap for you. It will let you install &os;, and - you can then install third-party - packages by downloading them using the ports/packages system (see - ) as - necessary. + Use the bootonly ISO to perform a + network install over the Internet. Additional software + can be installed as needed using + the Ports Collection as described in + . - Use the image of dvd1 if you want to - install a &os; - release and want a reasonable selection of third-party packages - on the disc as well. - - The additional disc images are useful, but not essential, - especially if you have high-speed access to the Internet. + Use dvd1 to + install &os; + and a selection of third-party packages + from the disc. - Write the CDs - - You must then write the CD images to disc. If you will be - doing this on another &os; system then see - for more information (in - particular, and - ). - - If you will be doing this on another platform then you will - need to use whatever utilities exist to control your CD writer on - that platform. The images provided are in the standard ISO format, - which many CD writing applications support. + Burn the Media + + Next, write the downloaded image(s) to disc. If using + another &os; system, refer to + and + for instructions. + + If using another platform, + use any burning utility that exists for + that platform. The images are in the standard ISO format + which most CD writing applications support. - If you are interested in building a customized - release of &os;, please see the To build a customized + release of &os;, refer to the Release Engineering Article. Creating a Local FTP Site with a &os; Disc installation network FTP &os; discs are laid out in the same way as the FTP site. This - makes it very easy for you to create a local FTP site that can be used - by other machines on your network when installing &os;. + makes it easy to create a local FTP site that can be used + by other machines on a network to install &os;. On the &os; computer that will host the FTP site, ensure - that the CDROM is in the drive, and mounted on - /cdrom. + that the CD/DVD is in the drive and mounted: &prompt.root; mount /cdrom - Create an account for anonymous FTP in - /etc/passwd. Do this by editing - /etc/passwd using &man.vipw.8; and adding + Create an account for anonymous FTP. Use &man.vipw.8; + to insert this line: ftp:*:99:99::0:0:FTP:/cdrom:/nonexistent Ensure that the FTP service is enabled in /etc/inetd.conf. - Anyone with network connectivity to your machine can now + Anyone with network connectivity to the machine can now chose a media type of FTP and type in ftp://your machine after picking Other in the FTP sites menu during the install. - If the boot media (floppy disks, usually) for your FTP + If the boot media for the FTP clients is not precisely the same version as that provided - by the local FTP site, then sysinstall - will not let you - complete the installation. If the versions are not similar and - you want to override this, you must go into the - Options menu and change distribution name to + by the local FTP site, &man.sysinstall.8; + will not + complete the installation. + To override this, go into the + Options menu and change the distribution + name to any. - This approach is OK for a machine that is on your local network, - and that is protected by your firewall. Offering up FTP services to - other machines over the Internet (and not your local network) - exposes your computer to the attention of crackers and other - undesirables. We strongly recommend that you follow good security - practices if you do this. + This approach is acceptable for a machine on the local + network which + is protected by a firewall. Offering anonymous FTP services + to + other machines over the Internet + exposes the computer to increased security risks. + It is strongly recommended to follow good security + practices when providing services over the Internet. - - Creating Installation Floppies - - - installation - floppies - - - If you must install from floppy disk (which we suggest you - do not do), either due to unsupported - hardware or simply because you insist on doing things the hard - way, you must first prepare some floppies for the installation. - - At a minimum, you will need as many 1.44 MB floppies - as it takes to hold all the files in the - base (base distribution) directory. If - you are preparing the floppies from &ms-dos;, then they - must be formatted using the &ms-dos; - FORMAT command. If you are using &windows;, - use Explorer to format the disks (right-click on the - A: drive, and select - Format). - - Do not trust factory pre-formatted - floppies. Format them again yourself, just to be sure. Many - problems reported by our users in the past have resulted from - the use of improperly formatted media, which is why we are - making a point of it now. - - If you are creating the floppies on another &os; machine, - a format is still not a bad idea, though you do not need to put - a &ms-dos; filesystem on each floppy. You can use the - bsdlabel and newfs - commands to put a UFS filesystem on them instead, as the - following sequence of commands (for a 3.5" 1.44 MB floppy) - illustrates: - - &prompt.root; fdformat -f 1440 fd0.1440 -&prompt.root; bsdlabel -w fd0.1440 floppy3 -&prompt.root; newfs -t 2 -u 18 -l 1 -i 65536 /dev/fd0 - - Then you can mount and write to them like any other - filesystem. - - After you have formatted the floppies, you will need to copy - the files to them. The distribution files are split into chunks - conveniently sized so that five of them will fit on a conventional - 1.44 MB floppy. Go through all your floppies, packing as many - files as will fit on each one, until you have all of the - distributions you want packed up in this fashion. Each - distribution should go into a subdirectory on the floppy, e.g.: - a:\base\base.aa, - a:\base\base.ab, and so on. - - - The base.inf file also needs to go on the - first floppy of the base set since it is read - by the installation program in order to figure out how many - additional pieces to look for when fetching and concatenating the - distribution. - - - Once you come to the Media screen during the install - process, select Floppy and you - will be prompted for the rest. - - - Installing from an &ms-dos; Partition + Installing from an &windows; Partition installation - from MS-DOS + from &windows; - To prepare for an installation from an &ms-dos; partition, + To prepare for an installation from a &windows; + partition, copy the files from the distribution into a directory - called freebsd in the root directory of the - partition. For example, c:\freebsd. The - directory structure of the CDROM or FTP site must be partially - reproduced within this directory, so we suggest using the &ms-dos; - xcopy command if you are copying it from a CD. + in the root directory of the + partition, such as c:\freebsd. Since the + directory structure must be + reproduced, it is recommended to use + robocopy when copying from a CD/DVD. For example, to prepare for a minimal installation of &os;: C:\> md c:\freebsd -C:\> xcopy e:\bin c:\freebsd\bin\ /s -C:\> xcopy e:\manpages c:\freebsd\manpages\ /s +C:\> robocopy e:\bin c:\freebsd\bin\ /s +C:\> robocopy e:\manpages c:\freebsd\manpages\ /s - Assuming that C: is where you have - free space and E: is where your CDROM + This example assumes that C: + has enough + free space and E: is where the + CD/DVD is mounted. - If you do not have a CDROM drive, you can download the + Alternatively, download the distribution from ftp.FreeBSD.org. + url="ftp://ftp.FreeBSD.org/pub/FreeBSD/releases/i386/&rel2.current;-RELEASE/">ftp.FreeBSD.org. Each distribution is in its own directory; for example, the base distribution can be found in the &rel.current;/base/ + url="ftp://ftp.FreeBSD.org/pub/FreeBSD/releases/i386/&rel2.current;-RELEASE/base/">&rel2.current;/base/ directory. - For as many distributions you wish to install from an &ms-dos; - partition (and you have the free space for), install each one - under c:\freebsd — the - BIN distribution is the only one required for - a minimum installation. - - - - Creating an Installation Tape - - - installation - from QIC/SCSI Tape - - Installing from tape is probably the easiest method, short - of an online FTP install or CDROM install. The installation - program expects the files to be simply tarred onto the tape. - After getting all of the distribution files you are interested - in, simply tar them onto the tape: - - &prompt.root; cd /freebsd/distdir -&prompt.root; tar cvf /dev/rwt0 dist1 ... dist2 - - When you perform the installation, you should make - sure that you leave enough room in some temporary directory - (which you will be allowed to choose) to accommodate the - full contents of the tape you have created. - Due to the non-random access nature of tapes, this method of - installation requires quite a bit of temporary storage. - - - When starting the installation, the tape must be in the - drive before booting from the boot - floppy. The installation probe may otherwise fail to find - it. - + Copy the distributions to install from a &windows; + partition to c:\freebsd. Both the + base and kernel + distributions are needed for + the most minimal installation. Before Installing over a Network installation network serial (PPP) installation network parallel (PLIP) installation network Ethernet - There are three types of network installations available. - Ethernet (a standard Ethernet controller), Serial port (PPP), or - Parallel port (PLIP (laplink cable)). - - For the fastest possible network installation, an - Ethernet adapter is always a good choice! &os; supports most - common PC Ethernet cards; a table of supported cards (and their - required settings) is provided in the Hardware Notes for each - release of &os;. If you are using one of the supported PCMCIA - Ethernet cards, also be sure that it is plugged in - before the laptop is powered on! &os; does - not, unfortunately, currently support hot insertion of PCMCIA cards + There are three types of network installations + available: + Ethernet, PPP, and + PLIP. + + For the fastest possible network installation, use an + Ethernet adapter. &os; supports most + common Ethernet cards. A list of supported cards + is provided in the Hardware Notes for each + release of &os;. If using a supported PCMCIA + Ethernet card, be sure that it is plugged in + before the system is powered on as + &os; does + not support hot insertion of PCMCIA cards during installation. - You will also need to know your IP address on the network, - the netmask value for your address class, and the name of your - machine. If you are installing over a PPP connection and do not - have a static IP, fear not, the IP address can be dynamically - assigned by your ISP. Your system administrator can tell you - which values to use for your particular network setup. If you - will be referring to other hosts by name rather than IP address, - you will also need a name server and possibly the address of a - gateway (if you are using PPP, it is your provider's IP address) - to use in talking to it. If you want to install by FTP via a - HTTP proxy, you will also need the proxy's address. - If you do not know the answers to all or most of these questions, - then you should really probably talk to your system administrator + Make note of the system's IP address, + subnet mask, hostname, default gateway address, and DNS + server addresses if these values are statically assigned. + If installing by FTP through a + HTTP proxy, make note of the proxy's address. + If you do not know these values, ask the system + administrator or ISP before trying this type of installation. - If you are using a modem, then PPP is almost certainly - your only choice. Make sure that you have your service - provider's information handy as you will need to know it fairly + If using a dialup modem, have the service + provider's PPP information handy as it is needed early in the installation process. - If you use PAP or CHAP to connect your ISP (in other words, if - you can connect to the ISP in &windows; without using a script), then - all you will need to do is type in dial at the - ppp prompt. Otherwise, you will need to - know how to dial your ISP using the AT commands - specific to your modem, as the PPP dialer provides only a very - simple terminal emulator. Please refer to the user-ppp handbook and FAQ - entries for further information. - If you have problems, logging can be directed to the screen using - the command set log local .... + If PAP or CHAP are used to connect to the + ISP without using a script, + type dial at the &os; + ppp prompt. Otherwise, + know how to dial the ISP using the + AT commands + specific to the modem, as the PPP dialer provides only a + simple terminal emulator. Refer to and + for further information. + Logging can be directed to the screen using + set log local .... If a hard-wired connection to another &os; - machine is available, you might also consider installing - over a laplink parallel port cable. The data rate - over the parallel port is much higher than what is typically - possible over a serial line (up to 50 kbytes/sec), thus - resulting in a quicker installation. + machine is available, the installation can occur + over a null-modem parallel port cable. The data rate + over the parallel port is higher than what is typically + possible over a serial line. - Before Installing via NFS + Before Installing via <acronym>NFS</acronym> installation network NFS - The NFS installation is fairly straight-forward. Simply - copy the &os; distribution files you want onto an NFS server - and then point the NFS media selection at it. - - If this server supports only privileged port - (as is generally the default for Sun workstations), you will - need to set the option NFS Secure in the - Options menu before installation can + To perform an NFS installation, + copy the needed &os; distribution files to an + NFS server + and then point the installer's NFS + media selection to it. + + If the server supports only a privileged + port, + set the option NFS Secure in the + Options menu so that the installation + can proceed. - If you have a poor quality Ethernet card which suffers - from very slow transfer rates, you may also wish to toggle the - NFS Slow flag. + If using a poor quality Ethernet card which suffers + from slow transfer rates, toggle the + NFS Slow flag to on. - In order for NFS installation to work, the server must - support subdir mounts, for example, if your - &os; &rel.current; distribution directory lives on: - ziggy:/usr/archive/stuff/FreeBSD, then + In order for an NFS installation to + work, the server must + support subdir mounts. For example, if the + &os; &rel.current; distribution lives on: + ziggy:/usr/archive/stuff/FreeBSD, ziggy will have to allow the direct mounting - of /usr/archive/stuff/FreeBSD, not just - /usr or - /usr/archive/stuff. - - In &os;'s /etc/exports file, this - is controlled by the options. Other NFS - servers may have different conventions. If you are getting - permission denied messages from the - server, then it is likely that you do not have this enabled + of /usr/archive/stuff/FreeBSD, + not just + /usr or + /usr/archive/stuff. + + In &os;, this + is controlled by using in + /etc/exports. Other + NFS + servers may have different conventions. If the server is + displaying + permission denied messages, + it is likely that this is not enabled properly. diff --git a/en_US.ISO8859-1/books/handbook/kernelconfig/chapter.xml b/en_US.ISO8859-1/books/handbook/kernelconfig/chapter.xml index 9f6bb1c207..e3ac479e91 100644 --- a/en_US.ISO8859-1/books/handbook/kernelconfig/chapter.xml +++ b/en_US.ISO8859-1/books/handbook/kernelconfig/chapter.xml @@ -1,1499 +1,1476 @@ Jim Mock Updated and restructured by Jake Hamby Originally contributed by Configuring the FreeBSD Kernel Synopsis kernel building a custom kernel The kernel is the core of the &os; operating system. It is responsible for managing memory, enforcing security controls, networking, disk access, and much more. While much of &os; is dynamically configurable, it is still occasionally necessary to configure and compile a custom kernel. After reading this chapter, you will know: When to build a custom kernel. How to customize a kernel configuration file. How to use the kernel configuration file to create and build a new kernel. How to install the new kernel. How to troubleshoot if things go wrong. All of the commands listed in the examples in this chapter should be executed as root. Why Build a Custom Kernel? Traditionally, &os; used a monolithic kernel. The kernel was one large program, supported a fixed list of devices, and in order to change the kernel's behavior, one had to compile a new kernel, and then reboot into the new kernel. Today, most of the functionality in the &os; kernel is contained in modules which can be dynamically loaded and unloaded from the kernel as necessary. This allows the running kernel to adapt immediately to new hardware or for new functionality to be brought into the kernel. This is known as a modular kernel. Occasionally, it is still necessary to perform static kernel configuration. This may be because the functionality is so tied to the kernel that it can not be made dynamically loadable. Some security environments prevent the loading and unloading of kernel modules, and require that only needed functionality is statically compiled into the kernel. Building a custom kernel is often a rite of passage for advanced BSD users. This process, while time consuming, can provide benefits to the &os; system. Unlike the GENERIC kernel, which must support a wide range of hardware, a custom kernel can be stripped down to only provide support for that computer's hardware. This has a number of benefits, such as: Faster boot time. Since the kernel will only probe the hardware on the system, the time it takes the system to boot can decrease. Lower memory usage. A custom kernel often uses less memory than the GENERIC kernel by omitting unused features and device drivers. This is important because the kernel code remains resident in physical memory at all times, preventing that memory from being used by applications. For this reason, a custom kernel is useful on a system with a small amount of RAM. Additional hardware support. A custom kernel can add in support for devices which are not present in the GENERIC kernel. Tom Rhodes Written by Finding the System Hardware Before venturing into kernel configuration, it would be wise to get an inventory of the machine's hardware. In cases where &os; is not the primary operating system, the inventory list can be created by viewing the current operating system configuration. For example, µsoft;'s Device Manager contains information about installed devices. Some versions of µsoft.windows; have a System icon which will display a screen where Device Manager may be accessed. If another operating system does not exist on the machine, the administrator must find this information out manually. One method is using &man.dmesg.8; and &man.man.1;. Most device drivers on &os; have a manual page, listing supported hardware. During the boot probe, found hardware will be listed. For example, the following lines indicate that the &man.psm.4; driver found a mouse: psm0: <PS/2 Mouse> irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Generic PS/2 mouse, device ID 0 This driver will need to be included in the custom kernel configuration file or loaded using &man.loader.conf.5;. On occasion, the data from dmesg will only show system messages instead of the boot probe output. In these situations, the output may be obtained by reading /var/run/dmesg.boot. Another method for finding hardware is to use &man.pciconf.8; which provides more verbose output. For example: ath0@pci0:3:0:0: class=0x020000 card=0x058a1014 chip=0x1014168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'AR5212 Atheros AR5212 802.11abg wireless' class = network subclass = ethernet This output, obtained by using pciconf , shows that the ath driver located a wireless Ethernet device. Type man ath to read &man.ath.4;. The flag, when passed to &man.man.1; can be used to provide useful information. For example, to display a list of manual pages which contain the specified word: &prompt.root; man -k Atheros ath(4) - Atheros IEEE 802.11 wireless network driver ath_hal(4) - Atheros Hardware Access Layer (HAL) Armed with a hardware inventory list, the process of building a custom kernel should appear less daunting. Kernel Drivers, Subsystems, and Modules kernel drivers / modules / subsystems Before building a custom kernel, consider the reason for doing so. If there is a need for specific hardware support, it may already exist as a module. Kernel modules exist in /boot/kernel and may be dynamically loaded into the running kernel using &man.kldload.8;. Most, if not all kernel drivers have a loadable module and manual page. For example, the &man.ath.4; wireless Ethernet driver has the following information in its manual page: Alternatively, to load the driver as a module at boot time, place the following line in &man.loader.conf.5;: if_ath_load="YES" Adding if_ath_load="YES" to /boot/loader.conf will enable loading this module dynamically at boot time. In some cases, there is no associated module. This is mostly true for certain subsystems. One way to tell if a driver is available is to check for the module itself. It is easy to remove support for a device or option and end up with a broken kernel. For example, if the &man.ata.4; driver is removed from the kernel configuration file, a system using ATA disk drivers may not boot. When in doubt, just leave support in the kernel. Building and Installing a Custom Kernel kernel building / installing It is required to have the full &os; source tree installed to build the kernel. The kernel build is located at /usr/src/sys. It contains a number of subdirectories representing different parts of the kernel. These include arch/conf, which contains the kernel configuration file, and compile, which is the staging area where the kernel will be built. arch contains subdirectories for each supported architecture: i386, amd64, ia64, powerpc, sparc64, and pc98. Everything inside a particular architecture's directory deals with that architecture only and the rest of the code is machine independent code common to all platforms. Notice the logical organization of the directory structure, with each supported device, file system, and option in its own subdirectory. The examples in this chapter assume the i386 architecture. If the system has a different architecture, change the path names accordingly. If /usr/src/ does not exist or it is empty, source has not been installed. The easiest way to install source is to use svn as described in . One should also create a symlink to /usr/src/sys/: &prompt.root; ln -s /usr/src/sys /sys Next, cd to arch/conf and copy the GENERIC configuration file to the name of the custom kernel. For example: &prompt.root; cd /usr/src/sys/i386/conf &prompt.root; cp GENERIC MYKERNEL Traditionally, this name is in all capital letters. When maintaining multiple &os; machines with different hardware, it is a good idea to name it after the machine's hostname. This example uses MYKERNEL. When finished customizing the kernel configuration file, save a backup copy to a location outside of /usr/src. Do not edit GENERIC directly. Alternately, keep the kernel configuration file elsewhere and create a symbolic link to the file in i386. For example: &prompt.root; cd /usr/src/sys/i386/conf &prompt.root; mkdir /root/kernels &prompt.root; cp GENERIC /root/kernels/MYKERNEL &prompt.root; ln -s /root/kernels/MYKERNEL Edit MYKERNEL with a text editor. The default editor is vi, whose usage is covered well in many books in the bibliography. An easier editor for beginners, called ee, is also available. Feel free to change the comment lines at the top to reflect the configuration or the changes made to differentiate it from GENERIC. If the GENERIC configuration file seems overwhelming, follow the descriptions in the Configuration File section slowly and carefully. After syncing the source tree with the latest sources, always read /usr/src/UPDATING before performing any update steps. This file describes any important issues or areas requiring special attention within the updated source code. /usr/src/UPDATING always matches the version of the &os; source and contains more up-to-date information than this Handbook. After saving the edits, compile the source code for the kernel. Building a Kernel It is required to have the full &os; source tree installed to build the kernel. cd to /usr/src: &prompt.root; cd /usr/src Compile the new kernel by specifying the name of the custom kernel configuration file: &prompt.root; make buildkernel KERNCONF=MYKERNEL Install the new kernel: &prompt.root; make installkernel KERNCONF=MYKERNEL By default, when a custom kernel is compiled, all kernel modules are rebuilt as well. To update a kernel faster or to build only custom modules, edit /etc/make.conf before starting to build the kernel: MODULES_OVERRIDE = linux acpi sound/sound sound/driver/ds1 ntfs This variable specifies the list of modules to build instead the default of building of all of them. WITHOUT_MODULES = linux acpi sound ntfs This variable sets up a list of top level modules to exclude from the build process. For other available variables, refer to &man.make.conf.5;. /boot/kernel.old The new kernel will be copied to /boot/kernel as /boot/kernel/kernel and the old kernel will be moved to /boot/kernel.old/kernel. Now, shutdown the system and reboot into the new kernel. If something goes wrong, refer to the troubleshooting instructions and the section which explains how to recover when the new kernel does not boot. Other files relating to the boot process, such as the boot &man.loader.8; and configuration, are stored in /boot. Third party or custom modules can be placed in /boot/kernel, although users should be aware that keeping modules in sync with the compiled kernel is very important. Modules not intended to run with the compiled kernel may result in instability. Joel Dahl Updated by The Configuration File kernel NOTES NOTES kernel configuration file The general format of a configuration file is quite simple. Each line contains a keyword and one or more arguments. For simplicity, most lines only contain one argument. Anything following a # is considered a comment and ignored. The following sections describe each keyword, in the order they are listed in GENERIC. For an exhaustive list of architecture dependent options and devices, refer to NOTES in the same directory as GENERIC for that architecture. For architecture independent options, refer to /usr/src/sys/conf/NOTES. An include directive is available for use in configuration files. This allows another configuration file to be included in the current one, making it easy to maintain small changes relative to an existing file. For example, if only a small number of additional options or drivers are required, this allows a delta to be maintained with respect to GENERIC: include GENERIC ident MYKERNEL options IPFIREWALL options DUMMYNET options IPFIREWALL_DEFAULT_TO_ACCEPT options IPDIVERT Using this method, the local configuration file expresses local differences from a GENERIC kernel. As upgrades are performed, new features added to GENERIC will be also be added to the local kernel unless they are specifically prevented using nooptions or nodevice. A comprehensive list of configuration directives and their descriptions may be found in &man.config.5;. The remainder of this chapter addresses the contents of a typical configuration file and the role various options and devices play. To build a file which contains all available options, run the following command as root: &prompt.root; cd /usr/src/sys/i386/conf && make LINT kernel configuration file The following is an example of the GENERIC kernel configuration file with various additional comments where needed for clarity. This example should match the copy in /usr/src/sys/i386/conf/GENERIC fairly closely. kernel options machine machine i386 This is the machine architecture. It must be either amd64, i386, ia64, pc98, powerpc, or sparc64. kernel options cpu cpu I486_CPU cpu I586_CPU cpu I686_CPU This option specifies the type of CPU. It is fine to have multiple instances of the CPU entries, but for a custom kernel it is best to specify the CPU. To determine the CPU type, review the boot messages in /var/run/dmesg.boot. kernel options ident ident GENERIC This is the identification of the kernel. Change this to the new kernel name, such as MYKERNEL. The value in the ident string will print when the kernel boots. #To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. &man.device.hints.5; is used to configure options for device drivers. The default location is /boot/device.hints. The hints option compiles these hints statically into the kernel so that there is no need to create /boot/device.hints. makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols This option enables debugging information when passed to &man.gcc.1;. options SCHED_ULE # ULE scheduler The default system scheduler for &os;. Keep this. options PREEMPTION # Enable kernel thread preemption Allows kernel threads to be preempted by higher priority threads. This helps with interactivity and allows interrupt threads to run sooner rather than waiting. options INET # InterNETworking Networking support. This is mandatory as most programs require at least loopback networking. options INET6 # IPv6 communications protocols This enables the IPv6 communication protocols. options FFS # Berkeley Fast Filesystem This is the basic hard drive file system. Leave it in if the system boots from the hard disk. options SOFTUPDATES # Enable FFS Soft Updates support This option enables Soft Updates in the kernel which helps to speed up write access on the disks. Even when this functionality is provided by the kernel, it must be turned on for specific disks. Review the output of &man.mount.8; to determine if Soft Updates is enabled. If the soft-updates option is not in the output, it can be activated using &man.tunefs.8; for existing file systems or &man.newfs.8; for new file systems. options UFS_ACL # Support for access control lists This option enables kernel support for access control lists (ACLs). This relies on the use of extended attributes and UFS2, and the feature is described in detail in . ACLs are enabled by default and should not be disabled in the kernel if they have been used previously on a file system, as this will remove the ACLs, changing the way files are protected in unpredictable ways. options UFS_DIRHASH # Improve performance on big directories This option includes functionality to speed up disk operations on large directories, at the expense of using additional memory. Keep this for a large server or interactive workstation, and remove it from smaller systems where memory is at a premium and disk access speed is less important, such as a firewall. options MD_ROOT # MD is a potential root device This option enables support for a memory backed virtual disk used as a root device. kernel options NFS kernel options NFS_ROOT options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFS_ROOT # NFS usable as /, requires NFSCLIENT The network file system (NFS). These lines can be commented unless the system needs to mount partitions from a NFS file server over TCP/IP. kernel options MSDOSFS options MSDOSFS # MSDOS Filesystem The &ms-dos; file system. Unless the system needs to mount a DOS formatted hard drive partition at boot time, comment this out. It will be automatically loaded the first time a DOS partition is mounted. The emulators/mtools package allows access to DOS floppies without having to mount and unmount them and does not require MSDOSFS. options CD9660 # ISO 9660 Filesystem The ISO 9660 file system for CDROMs. Comment it out if the system does not have a CDROM drive or only mounts data CDs occasionally since it will be dynamically loaded the first time a data CD is mounted. Audio CDs do not need this file system. options PROCFS # Process filesystem (requires PSEUDOFS) The process file system. This is a pretend file system mounted on /proc which allows some programs to provide more information on what processes are running. Use of PROCFS is not required under most circumstances, as most debugging and monitoring tools have been adapted to run without PROCFS. The default installation will not mount this file system by default. options PSEUDOFS # Pseudo-filesystem framework Kernels making use of PROCFS must also include support for PSEUDOFS. options GEOM_PART_GPT # GUID Partition Tables. Adds support for GUID - Partition Tables (GPT. GPT + Partition Tables (GPT). GPT provides the ability to have a large number of partitions per disk, 128 in the standard configuration. options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] Compatibility with 4.3BSD. Leave this in as some programs will act strangely if this is commented out. options COMPAT_FREEBSD4 # Compatible with &os;4 This option is required to support applications compiled on older versions of &os; that use older system call interfaces. It is recommended that this option be used on all &i386; systems that may run older applications. Platforms that gained support after &os; 4.X, such as ia64 and &sparc64;, do not require this option. options COMPAT_FREEBSD5 # Compatible with &os;5 This option is required to support applications compiled on &os; 5.X versions that use &os; 5.X system call interfaces. options COMPAT_FREEBSD6 # Compatible with &os;6 This option is required to support applications compiled on &os; 6.X versions that use &os; 6.X system call interfaces. options COMPAT_FREEBSD7 # Compatible with &os;7 This option is required on &os; 8 and above to support applications compiled on &os; 7.X versions that use &os; 7.X system call interfaces. options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI This causes the kernel to pause for 5 seconds before probing each SCSI device in the system. If the system only has IDE hard drives, ignore this or lower the number to speed up booting. However, if &os; has trouble recognizing the SCSI devices, the number will have to be raised again. options KTRACE # ktrace(1) support This enables kernel process tracing, which is useful in debugging. options SYSVSHM # SYSV-style shared memory This option provides for System V shared memory. The most common use of this is the XSHM extension in X, which many graphics-intensive programs will automatically take advantage of for extra speed. If Xorg is installed, include this. options SYSVMSG # SYSV-style message queues Support for System V messages. This option only adds a few hundred bytes to the kernel. options SYSVSEM # SYSV-style semaphores Support for System V semaphores. Less commonly used, but only adds a few hundred bytes to the kernel. Using with &man.ipcs.1; will list any processes using each of these System V facilities. options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions Real-time extensions added in the 1993 &posix;. Certain applications in the Ports Collection use these. options KBD_INSTALL_CDEV # install a CDEV entry in /dev This option is required to allow the creation of keyboard device nodes in /dev. - options ADAPTIVE_GIANT # Giant mutex is adaptive. - - Giant is the name of a mutual exclusion mechanism, a - sleep mutex, that protects a large set of kernel resources. - Today, this is an unacceptable performance bottleneck which - is actively being replaced with locks that protect individual - resources. The ADAPTIVE_GIANT option causes - Giant to be included in the set of mutexes adaptively spun on. - When a thread wants to lock the Giant mutex, but it is already - locked by a thread on another CPU, the first thread will keep - running and wait for the lock to be released. Normally, the - thread would instead go back to sleep and wait for its next - chance to run. If unsure, leave this in. - - - Beginning with &os; 8.0, all mutexes are adaptive by - default, unless explicitly set to non-adaptive by compiling - with the NO_ADAPTIVE_MUTEXES option. As a - result, Giant is adaptive by default now, and the - ADAPTIVE_GIANT option has been removed - from the kernel configuration. - - kernel options SMP device apic # I/O APIC This device enables the use of the I/O APIC for interrupt delivery. It can be used in both uni-processor and SMP kernels, but is required for SMP kernels. Add options SMP to include support for multiple processors. This device exists only on the i386 architecture and this configuration line should not be used on other architectures. device eisa Include this for systems with an EISA motherboard. This enables auto-detection and configuration support for all devices on the EISA bus. device pci Include this for systems with a PCI motherboard. This enables auto-detection of PCI cards and gatewaying from the PCI to ISA bus. # Floppy drives device fdc This is the floppy drive controller. # ATA and ATAPI devices device ata This driver supports all ATA and ATAPI devices. Only one device ata line is needed for the kernel to detect all PCI ATA/ATAPI devices on modern machines. device atadisk # ATA disk drives This is needed along with device ata for ATA disk drives. device ataraid # ATA RAID drives This is needed along with device ata for ATA RAID drives. device atapicd # ATAPI CDROM drives This is needed along with device ata for ATAPI CDROM drives. device atapifd # ATAPI floppy drives This is needed along with device ata for ATAPI floppy drives. device atapist # ATAPI tape drives This is needed along with device ata for ATAPI tape drives. options ATA_STATIC_ID # Static device numbering This makes the controller number static. Without this, the device numbers are dynamically allocated. # SCSI Controllers device ahb # EISA AHA1742 family device ahc # AHA2940 and onboard AIC7xxx devices options AHC_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~128k to driver. device ahd # AHA39320/29320 and onboard AIC79xx devices options AHD_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~215k to driver. device amd # AMD 53C974 (Teckram DC-390(T)) device isp # Qlogic family #device ispfw # Firmware for QLogic HBAs- normally a module device mpt # LSI-Logic MPT-Fusion #device ncr # NCR/Symbios Logic device sym # NCR/Symbios Logic (newer chipsets + those of `ncr') device trm # Tekram DC395U/UW/F DC315U adapters device adv # Advansys SCSI adapters device adw # Advansys wide SCSI adapters device aha # Adaptec 154x SCSI adapters device aic # Adaptec 15[012]x SCSI adapters, AIC-6[23]60. device bt # Buslogic/Mylex MultiMaster SCSI adapters device ncv # NCR 53C500 device nsp # Workbit Ninja SCSI-3 device stg # TMC 18C30/18C50 In this section, comment out any SCSI controllers not on the system. For an IDE only system, these lines can be removed. The *_REG_PRETTY_PRINT lines are debugging options for their respective drivers. # SCSI peripherals device scbus # SCSI bus (required for SCSI) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) device ses # SCSI Environmental Services (and SAF-TE) Comment out any SCSI peripherals not on the system. If the system only has IDE hardware, these lines can be removed completely. The USB &man.umass.4; driver and a few other drivers use the SCSI subsystem even though they are not real SCSI devices. Do not remove SCSI support if any such drivers are included in the kernel configuration. # RAID controllers interfaced to the SCSI subsystem device amr # AMI MegaRAID device arcmsr # Areca SATA II RAID device asr # DPT SmartRAID V, VI and Adaptec SCSI RAID device ciss # Compaq Smart RAID 5* device dpt # DPT Smartcache III, IV - See NOTES for options device hptmv # Highpoint RocketRAID 182x device hptrr # Highpoint RocketRAID 17xx, 22xx, 23xx, 25xx device iir # Intel Integrated RAID device ips # IBM (Adaptec) ServeRAID device mly # Mylex AcceleRAID/eXtremeRAID device twa # 3ware 9000 series PATA/SATA RAID # RAID controllers device aac # Adaptec FSA RAID device aacp # SCSI passthrough for aac (requires CAM) device ida # Compaq Smart RAID device mfi # LSI MegaRAID SAS device mlx # Mylex DAC960 family device pst # Promise Supertrak SX6000 device twe # 3ware ATA RAID Supported RAID controllers. If the system does not have any of these, comment them out or remove them. # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller The atkbdc keyboard controller provides I/O services for the AT keyboard and PS/2 style pointing devices. This controller is required by &man.atkbd.4; and &man.psm.4;. device atkbd # AT keyboard The &man.atkbd.4; driver, together with the &man.atkbdc.4; controller, provides access to the AT 84 keyboard or the AT enhanced keyboard which is connected to the AT keyboard controller. device psm # PS/2 mouse Use this device if the mouse plugs into the PS/2 mouse port. device kbdmux # keyboard multiplexer Basic support for keyboard multiplexing. If the system does not use more than one keyboard, this line can be safely removed. device vga # VGA video card driver The &man.vga.4; video card driver. device splash # Splash screen and screen saver support Required by the boot splash screen and screen savers. # syscons is the default console driver, resembling an SCO console device sc &man.sc.4; is the default console driver and resembles a SCO console. Since most full-screen programs access the console through a terminal database library like termcap, it should not matter whether this or vt, the VT220 compatible console driver, is used. When a user logs in, the TERM variable can be set to scoansi if full-screen programs have trouble running under this console. # Enable this for the pcvt (VT220 compatible) console driver #device vt #options XSERVER # support for X server on a vt console #options FAT_CURSOR # start with block cursor This is a VT220-compatible console driver, backward compatible to VT100/102. It works well on some laptops which have hardware incompatibilities with sc. Users may need to set TERM to vt100 or vt220 after login. This driver is useful when connecting to a large number of different machines over the network, where termcap or terminfo entries for the sc device are not available as vt100 should be available on virtually any platform. device agp Include this if the system has an AGP card. This will enable support for AGP and AGP GART for boards which have these features. # Add suspend/resume support for the i8254. device pmtimer Timer device driver for power management events, such as APM and ACPI. # PCCARD (PCMCIA) support # PCMCIA and cardbus bridge support device cbb # cardbus (yenta) bridge device pccard # PC Card (16-bit) bus device cardbus # CardBus (32-bit) bus PCMCIA support. Keep this on laptop systems. # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports These are the serial ports referred to as COM ports in &windows;. If the system has an internal modem on COM4 and a serial port at COM2, change the IRQ of the modem to 2. For a multiport serial card, refer to &man.sio.4; for more information on the proper values to add to /boot/device.hints. Some video cards, notably those based on S3 chips, use I/O addresses in the form of 0x*2e8. Since many cheap serial cards do not fully decode the 16-bit I/O address space, they clash with these cards, making the COM4 port practically unavailable. Each serial port is required to have a unique IRQ and the default IRQs for COM3 and COM4 cannot be used. The exception is multiport cards where shared interrupts are supported. # Parallel port device ppc This is the ISA bus parallel port interface. device ppbus # Parallel port bus (required) Provides support for the parallel port bus. device lpt # Printer Adds support for parallel port printers. All three of the above are required to enable parallel printer support. device ppi # Parallel port interface device The general-purpose I/O (geek port) + IEEE1284 I/O. #device vpo # Requires scbus and da zip drive This is for an Iomega Zip drive. It requires scbus and da support. Best performance is achieved with ports in EPP 1.9 mode. #device puc Uncomment this device if the system has a dumb serial or parallel PCI card that is supported by the &man.puc.4; glue driver. # PCI Ethernet NICs. device de # DEC/Intel DC21x4x (Tulip) device em # Intel PRO/1000 adapter Gigabit Ethernet Card device ixgb # Intel PRO/10GbE Ethernet Card device txp # 3Com 3cR990 (Typhoon) device vx # 3Com 3c590, 3c595 (Vortex) Various PCI network card drivers. Comment out or remove any of these which are not present in the system. # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support MII bus support is required for some PCI 10/100 Ethernet NICs, namely those which use MII-compliant transceivers or implement transceiver control interfaces that operate like an MII. Adding device miibus to the kernel config pulls in support for the generic miibus API and all of the PHY drivers, including a generic one for PHYs that are not specifically handled by an individual driver. device bce # Broadcom BCM5706/BCM5708 Gigabit Ethernet device bfe # Broadcom BCM440x 10/100 Ethernet device bge # Broadcom BCM570xx Gigabit Ethernet device dc # DEC/Intel 21143 and various workalikes device fxp # Intel EtherExpress PRO/100B (82557, 82558) device lge # Level 1 LXT1001 gigabit ethernet device msk # Marvell/SysKonnect Yukon II Gigabit Ethernet device nge # NatSemi DP83820 gigabit ethernet device nve # nVidia nForce MCP on-board Ethernet Networking device pcn # AMD Am79C97x PCI 10/100 (precedence over 'lnc') device re # RealTek 8139C+/8169/8169S/8110S device rl # RealTek 8129/8139 device sf # Adaptec AIC-6915 (Starfire) device sis # Silicon Integrated Systems SiS 900/SiS 7016 device sk # SysKonnect SK-984x & SK-982x gigabit Ethernet device ste # Sundance ST201 (D-Link DFE-550TX) device stge # Sundance/Tamarack TC9021 gigabit Ethernet device ti # Alteon Networks Tigon I/II gigabit Ethernet device tl # Texas Instruments ThunderLAN device tx # SMC EtherPower II (83c170 EPIC) device vge # VIA VT612x gigabit ethernet device vr # VIA Rhine, Rhine II device wb # Winbond W89C840F device xl # 3Com 3c90x (Boomerang, Cyclone) Drivers that use the MII bus controller code. # ISA Ethernet NICs. pccard NICs included. device cs # Crystal Semiconductor CS89x0 NIC # 'device ed' requires 'device miibus' device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards device ex # Intel EtherExpress Pro/10 and Pro/10+ device ep # Etherlink III based cards device fe # Fujitsu MB8696x based cards device ie # EtherExpress 8/16, 3C507, StarLAN 10 etc. device lnc # NE2100, NE32-VL Lance Ethernet cards device sn # SMC's 9000 series of Ethernet chips device xe # Xircom pccard Ethernet # ISA devices that use the old ISA shims #device le ISA Ethernet drivers. See /usr/src/sys/i386/conf/NOTES for details of which cards are supported by which driver. # Wireless NIC cards device wlan # 802.11 support Generic 802.11 support. This line is required for wireless networking. device wlan_wep # 802.11 WEP support device wlan_ccmp # 802.11 CCMP support device wlan_tkip # 802.11 TKIP support Crypto support for 802.11 devices. These lines are needed on systems which use encryption and 802.11i security protocols. device an # Aironet 4500/4800 802.11 wireless NICs. device ath # Atheros pci/cardbus NIC's device ath_hal # Atheros HAL (Hardware Access Layer) device ath_rate_sample # SampleRate tx rate control for ath device awi # BayStack 660 and others device ral # Ralink Technology RT2500 wireless NICs. device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs. #device wl # Older non 802.11 Wavelan wireless NIC. Support for various wireless cards. # Pseudo devices device loop # Network loopback This is the generic loopback device for TCP/IP. This is mandatory. device random # Entropy device Cryptographically secure random number generator. device ether # Ethernet support ether is only needed if the system has an Ethernet card. It includes generic Ethernet protocol code. device sl # Kernel SLIP sl provides SLIP support. This has been almost entirely supplanted by PPP, which is easier to set up, better suited for modem-to-modem connection, and more powerful. device ppp # Kernel PPP This is for kernel PPP support for dial-up connections. There is also a version of PPP implemented as a userland application that uses tun and offers more flexibility and features such as demand dialing. device tun # Packet tunnel. This is used by the userland PPP software. See the PPP section of the Handbook for more information. device pty # Pseudo-ttys (telnet etc) This is a pseudo-terminal or simulated login port. It is used by incoming telnet and rlogin sessions, xterm, and some other applications such as Emacs. device md # Memory disks Memory disk pseudo-devices. device gif # IPv6 and IPv4 tunneling This implements IPv6 over IPv4 tunneling, IPv4 over IPv6 tunneling, IPv4 over IPv4 tunneling, and IPv6 over IPv6 tunneling. The gif device is auto-cloning, and will create device nodes as needed. device faith # IPv6-to-IPv4 relaying (translation) This pseudo-device captures packets that are sent to it and diverts them to the IPv4/IPv6 translation daemon. # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter The Berkeley Packet Filter pseudo-device allows network interfaces to be placed in promiscuous mode, capturing every packet on a broadcast network such as an Ethernet network. These packets can be captured to disk and or examined using &man.tcpdump.1;. The &man.bpf.4; device is also used by &man.dhclient.8;. If DHCP is used, leave this uncommented. # USB support device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices device ugen # Generic device uhid # Human Interface Devices device ukbd # Keyboard device ulpt # Printer device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse device ural # Ralink Technology RT2500USB wireless NICs device urio # Diamond Rio 500 MP3 player device uscanner # Scanners # USB Ethernet, requires mii device aue # ADMtek USB Ethernet device axe # ASIX Electronics USB Ethernet device cdce # Generic USB over Ethernet device cue # CATC USB Ethernet device kue # Kawasaki LSI USB Ethernet device rue # RealTek RTL8150 USB Ethernet Support for various USB devices. # FireWire support device firewire # FireWire bus code device sbp # SCSI over FireWire (Requires scbus and da) device fwe # Ethernet over FireWire (non-standard!) Support for various Firewire devices. For more information and additional devices supported by &os;, see /usr/src/sys/i386/conf/NOTES. Large Memory Configurations (<acronym>PAE</acronym>) Physical Address Extensions (PAE) large memory Large memory configuration machines require access to more than the 4 gigabyte limit on User+Kernel Virtual Address (KVA) space. Due to this limitation, Intel added support for 36-bit physical address space access in the &pentium; Pro and later line of CPUs. The Physical Address Extension (PAE) capability of the &intel; &pentium; Pro and later CPUs allows memory configurations of up to 64 gigabytes. &os; provides support for this capability via the kernel configuration option, available in all current release versions of &os;. Due to the limitations of the Intel memory architecture, no distinction is made for memory above or below 4 gigabytes. Memory allocated above 4 gigabytes is simply added to the pool of available memory. To enable PAE support in the kernel, add the following line to the kernel configuration file: options PAE The PAE support in &os; is only available for &intel; IA-32 processors. It should also be noted that the PAE support in &os; has not received wide testing, and should be considered beta quality compared to other stable features of &os;. PAE support in &os; has a few limitations: A process is not able to access more than 4 gigabytes of virtual memory space. Device drivers that do not use the &man.bus.dma.9; interface will cause data corruption in a PAE enabled kernel and are not recommended for use. For this reason, a PAE kernel configuration file is provided in &os; which excludes all drivers not known to work in a PAE enabled kernel. Some system tunables determine memory resource usage by the amount of available physical memory. Such tunables can unnecessarily over-allocate due to the large memory nature of a PAE system. One such example is the kern.maxvnodes sysctl, which controls the maximum number of vnodes allowed in the kernel. It is advised to adjust this and other such tunables to a reasonable value. It might be necessary to increase the kernel virtual address (KVA) space or to reduce the amount of specific kernel resource that is heavily used in order to avoid KVA exhaustion. The kernel option can be used for increasing the KVA space. For performance and stability concerns, it is advised to consult &man.tuning.7;. &man.pae.4; contains up-to-date information on &os;'s PAE support. If Something Goes Wrong There are four categories of trouble that can occur when building a custom kernel. They are: config fails: If &man.config.8; fails, it is probably a simple error. Fortunately, &man.config.8; will print the line number that it had trouble with. For example, for this message: config: line 17: syntax error Make sure the keyword on line 17 is typed correctly by comparing it to the GENERIC kernel or another reference. make fails: If make fails, it usually signals an error in the kernel description which is not severe enough for &man.config.8; to catch. Review the configuration, and if you still cannot resolve the problem, send an email to the &a.questions; with the kernel configuration. The kernel does not boot: If the new kernel does not boot, or fails to recognize devices, do not panic! Fortunately, &os; has an excellent mechanism for recovering from incompatible kernels. Simply choose the kernel to boot from at the &os; boot loader. This can be accessed when the system boot menu - appears by selecting the Escape to a loader + appears by selecting the Escape to a loader prompt option. At the prompt, type boot kernel.old, or the name of any other kernel that will boot properly. When reconfiguring a kernel, it is always a good idea to keep a kernel that is known to work on hand. After booting with a good kernel, check over the configuration file and try to build it again. One helpful resource is /var/log/messages which records the kernel messages from every successful boot. Also, &man.dmesg.8; will print the kernel messages from the current boot. When troubleshooting a kernel, make sure to keep GENERIC, or some other kernel that is known to work, on hand as a different name that will not get erased on the next build. Do not rely on kernel.old because when installing a new kernel, kernel.old is overwritten with the last installed kernel which may be non-functional. As soon as possible, move the working kernel to the proper /boot/kernel location or commands such as &man.ps.1; may not work properly. To do this, simply rename the directory containing the good kernel: &prompt.root; mv /boot/kernel /boot/kernel.bad &prompt.root; mv /boot/kernel.good /boot/kernel The kernel works, but &man.ps.1; does not work any more: If the kernel version differs from the one that the system utilities have been built with, for example, a -CURRENT kernel on a -RELEASE, many system status commands like &man.ps.1; and &man.vmstat.8; will not work. To fix this, recompile and install a world built with the same version of the source tree as the kernel. This is one reason why it is not a good idea to use a different version of the kernel than the rest of the operating system. diff --git a/en_US.ISO8859-1/books/handbook/mac/chapter.xml b/en_US.ISO8859-1/books/handbook/mac/chapter.xml index facf372522..835959f2ab 100644 --- a/en_US.ISO8859-1/books/handbook/mac/chapter.xml +++ b/en_US.ISO8859-1/books/handbook/mac/chapter.xml @@ -1,1947 +1,1943 @@ Tom Rhodes Written by Mandatory Access Control Synopsis MAC Mandatory Access Control MAC &os; 5.X introduced new security extensions from the TrustedBSD Project based on the &posix;.1e draft. Two of the most significant new security mechanisms are file system Access Control Lists (ACLs) and Mandatory Access Control (MAC) facilities. MAC allows new access control modules to be loaded, implementing new security policies. Some modules provide protections for a narrow subset of the system, hardening a particular service. Others provide comprehensive labeled security across all subjects and objects. The mandatory part of the definition indicates that enforcement of controls is performed by administrators and the operating system. This is in contrast to the default security mechanism of Discretionary Access Control (DAC where enforcement is left to the discretion of users. This chapter focuses on the MAC framework and the set of pluggable security policy modules &os; provides for enabling various security mechanisms. After reading this chapter, you will know: Which MAC security policy modules are included in &os; and their associated mechanisms. The capabilities of MAC security policy modules as well as the difference between a labeled and non-labeled policy. How to efficiently configure a system to use the MAC framework. How to configure the different security policy modules included with the MAC framework. How to implement a more secure environment using the MAC framework. How to test the MAC configuration to ensure the framework has been properly implemented. Before reading this chapter, you should: Understand &unix; and &os; basics (). Have some familiarity with security and how it pertains to &os; (). Improper MAC configuration may cause loss of system access, aggravation of users, or inability to access the features provided by Xorg. More importantly, MAC should not be relied upon to completely secure a system. The MAC framework only augments an existing security policy. Without sound security practices and regular security checks, the system will never be completely secure. The examples contained within this chapter are for demonstration purposes and the example settings should not be implemented on a production system. Implementing any security policy takes a good deal of understanding, proper design, and thorough testing. What Will Not Be Covered This chapter covers a broad range of security issues relating to the MAC framework. The development of new MAC security policy modules will not be covered. A number of security policy modules included with the MAC framework have specific characteristics which are provided for both testing and new module development. These include &man.mac.test.4;, &man.mac.stub.4; and &man.mac.none.4;. For more information on these security policy modules and the various mechanisms they provide, refer to their manual pages. Key Terms in This Chapter Before reading this chapter, a few key terms must be explained: compartment: a set of programs and data to be partitioned or separated, where users are given explicit access to specific component of a system. A compartment represents a grouping, such as a work group, department, project, or topic. Compartments make it possible to implement a need-to-know-basis security policy. high-watermark: this type of policy permits the raising of security levels for the purpose of accessing higher level information. In most cases, the original level is restored after the process is complete. Currently, the &os; MAC framework does not include this type of policy. integrity: the level of trust which can be placed on data. As the integrity of the data is elevated, so does the ability to trust that data. label: a security attribute which can be applied to files, directories, or other items in the system. It could be considered a confidentiality stamp. When a label is placed on a file, it describes the security properties of that file and will only permit access by files, users, and resources with a similar security setting. The meaning and interpretation of label values depends on the policy configuration. Some policies treat a label as representing the integrity or secrecy of an object while other policies might use labels to hold rules for access. level: the increased or decreased setting of a security attribute. As the level increases, its security is considered to elevate as well. low-watermark: this type of policy permits lowering security levels for the purpose of accessing information which is less secure. In most cases, the original security level of the user is restored after the process is complete. The only security policy module in &os; to use this is &man.mac.lomac.4;. multilabel: this property is a file system option which can be set in single user mode using &man.tunefs.8;, during boot using &man.fstab.5;, or during the creation of a new file system. This option permits an administrator to apply different MAC labels on different objects. This option only applies to security policy modules which support labeling. object: an entity through which information flows under the direction of a subject. This includes directories, files, fields, screens, keyboards, memory, magnetic storage, printers or any other data storage or moving device. An object is a data container or a system resource. Access to an object effectively means access to its data. policy: a collection of rules which defines how objectives are to be achieved. A policy usually documents how certain items are to be handled. This chapter considers the term policy to be a security policy, or a collection of rules which controls the flow of data and information and defines who has access to that data and information. sensitivity: usually used when discussing Multilevel Security MLS. A sensitivity level describes how important or secret the data should be. As the sensitivity level increases, so does the importance of the secrecy, or confidentiality, of the data. single label: a policy where the entire file system uses one label to enforce access control over the flow of data. Whenever is not set, all files will conform to the same label setting. subject: any active entity that causes information to flow between objects such as a user, user process, or system process. On &os;, this is almost always a thread acting in a process on behalf of a user. Explanation of MAC With all of these new terms in mind, consider how the MAC framework augments the security of the system as a whole. The various security policy modules provided by the MAC framework could be used to protect the network and file systems or to block users from accessing certain ports and sockets. Perhaps the best use of the policy modules is to load several security policy modules at a time in order to provide a MLS environment. This approach differs from a hardening policy, which typically hardens elements of a system which are used only for specific purposes. The downside to MLS is increased administrative overhead. The overhead is minimal when compared to the lasting effect of a framework which provides the ability to pick and choose which policies are required for a specific configuration and which keeps performance overhead down. The reduction of support for unneeded policies can increase the overall performance of the system as well as offer flexibility of choice. A good implementation would consider the overall security requirements and effectively implement the various security policy modules offered by the framework. A system utilizing MAC guarantees that a user will not be permitted to change security attributes at will. All user utilities, programs, and scripts must work within the constraints of the access rules provided by the selected security policy modules and total control of the MAC access rules are in the hands of the system administrator. It is the duty of the system administrator to carefully select the correct security policy modules. For an environment that needs to limit access control over the network, the &man.mac.portacl.4;, &man.mac.ifoff.4;, and &man.mac.biba.4; policy modules make good starting points. For an environment where strict confidentiality of file system objects is required, consider the &man.mac.bsdextended.4; and &man.mac.mls.4; policy modules. Policy decisions could be made based on network configuration. If only certain users should be permitted access to &man.ssh.1;, the &man.mac.portacl.4; policy module is a good choice. In the case of file systems, access to objects might be considered confidential to some users, but not to others. As an example, a large development team might be broken off into smaller projects where developers in project A might not be permitted to access objects written by developers in project B. Yet both projects might need to access objects created by developers in project C. Using the different security policy modules provided by the MAC framework, users could be divided into these groups and then given access to the appropriate objects. Each security policy module has a unique way of dealing with the overall security of a system. Module selection should be based on a well thought out security policy which may require revision and reimplementation. Understanding the different security policy modules offered by the MAC framework will help administrators choose the best policies for their situations. Implementing MAC is much like implementing a firewall, care must be taken to prevent being completely locked out of the system. The ability to revert back to a previous configuration should be considered and the implementation of MAC remotely should be done with extreme caution. Understanding MAC Labels A MAC label is a security attribute which may be applied to subjects and objects throughout the system. When setting a label, the administrator must be able to comprehend what exactly is being done and understand any implications in order to prevent unexpected or undesired behavior of the system. The attributes available on an object depend on the loaded policy module as policy modules interpret their attributes in different ways. The security label on an object is used as a part of a security access control decision by a policy. With some policies, the label contains all of the information necessary to make a decision. In other policies, the labels may be processed as part of a larger rule set. For instance, setting the label of biba/low on a file will represent a label maintained by the Biba security policy module, with a value of low. A few policy modules which support the labeling feature in &os; offer three specific predefined labels: low, high, and equal. Such policy modules enforce access control in a different manner with each policy module, where the low label is the lowest setting, the equal label sets the subject or object to be disabled or unaffected, and the high label enforces the highest setting available in the Biba and MLS policy modules. Within single label file system environments, only one label may be used on objects. This label enforces one set of access permissions across the entire system and in many environments may be all that is required. There are a few cases where multiple labels may be set on objects or subjects in the file system by passing to &man.tunefs.8;. In the case of Biba and MLS, a numeric label may be set to indicate the precise level of hierarchical control. This numeric level is used to partition or sort information into different groups of classification only permitting access to that group or a higher group level. In most cases, the administrator will set up a single label to use throughout the file system. This is similar to DAC to some extent as root is the one in control and who configures the policies so that users are placed in the appropriate categories/access levels. Alas, many policy modules can restrict the root user as well. Basic control over objects will then be released to the group, but root may revoke or modify the settings at any time. This is the hierarchical/clearance model covered by policies such as Biba and MLS. Label Configuration Virtually all aspects of label policy module configuration will be performed using the base system utilities. These commands provide a simple interface for object or subject configuration or the manipulation and verification of the configuration. All configuration may be done using &man.setfmac.8; and &man.setpmac.8;. setfmac is used to set MAC labels on system objects while setpmac is used to set the labels on system subjects. Observe: &prompt.root; setfmac biba/high test If the configuration is successful, the prompt will be returned without error. A common error is Permission denied which usually occurs when the label is being set or modified on an object which is restricted.Other conditions may produce different failures. For instance, the file may not be owned by the user attempting to relabel the object, the object may not exist, or the object may be read only. A mandatory policy will not allow the process to relabel the file, maybe because of a property of the file, a property of the process, or a property of the proposed new label value. For example, a user running at low integrity tries to change the label of a high integrity file. Or perhaps a user running at low integrity tries to change the label of a low integrity file to a high integrity label. The system administrator may use the following commands to overcome this: &prompt.root; setfmac biba/high test Permission denied &prompt.root; setpmac biba/low setfmac biba/high test &prompt.root; getfmac test test: biba/high setpmac can be used to override the policy module's settings by assigning a different label to the invoked process. getpmac is usually used with currently running processes, such as sendmail. It takes a process ID in place of a command. If users attempt to manipulate a file not in their access, subject to the rules of the loaded policy modules, the Operation not permitted error will be displayed by the mac_set_link function. Common Label Types For the &man.mac.biba.4;, &man.mac.mls.4; and &man.mac.lomac.4; policy modules, the ability to assign simple labels is provided. These take the form of high, equal, and low, where: The low label is considered the lowest label setting an object or subject may have. Setting this on objects or subjects blocks their access to objects or subjects marked high. The equal label should only be placed on objects considered to be exempt from the policy. The high label grants an object or subject the highest possible setting. With respect to each policy module, each of those settings will establish a different information flow directive. Refer to the manual pages of the module to determine the traits of these generic label configurations. Advanced Label Configuration Numeric grade labels are used for comparison:compartment+compartment. For example: biba/10:2+3+6(5:2+3-20:2+3+4+5+6) may be interpreted as Biba Policy Label/Grade 10:Compartments 2, 3 and 6: (grade 5 ...) In this example, the first grade would be considered the effective grade with effective compartments, the second grade is the low grade, and the last one is the high grade. In most configurations, these settings will not be used as they are advanced configurations. System objects only have a current grade/compartment. System subjects reflect the range of available rights in the system, and network interfaces, where they are used for access control. The grade and compartments in a subject and object pair are used to construct a relationship known as dominance, in which a subject dominates an object, the object dominates the subject, neither dominates the other, or both dominate each other. The both dominate case occurs when the two labels are equal. Due to the information flow nature of Biba, a user has rights to a set of compartments that might correspond to projects, but objects also have a set of compartments. Users may have to subset their rights using su or setpmac in order to access objects in a compartment from which they are not restricted. Users and Label Settings Users are required to have labels so that their files and processes properly interact with the security policy defined on the system. This is configured in login.conf using login classes. Every policy module that uses labels will implement the user class setting. An example entry containing every policy module setting is displayed below: default:\ :copyright=/etc/COPYRIGHT:\ :welcome=/etc/motd:\ :setenv=MAIL=/var/mail/$,BLOCKSIZE=K:\ :path=~/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:\ :manpath=/usr/share/man /usr/local/man:\ :nologin=/usr/sbin/nologin:\ :cputime=1h30m:\ :datasize=8M:\ :vmemoryuse=100M:\ :stacksize=2M:\ :memorylocked=4M:\ :memoryuse=8M:\ :filesize=8M:\ :coredumpsize=8M:\ :openfiles=24:\ :maxproc=32:\ :priority=0:\ :requirehome:\ :passwordtime=91d:\ :umask=022:\ :ignoretime@:\ :label=partition/13,mls/5,biba/10(5-15),lomac/10[2]: To set the user class default label which will be enforced by MAC, use . Users are never permitted to modify this value. In a real configuration, however, the administrator would never enable every policy module. It is recommended that the rest of this chapter be reviewed before any configuration is implemented. Users may change their label after they login, subject to the constraints of the policy. The example above tells the Biba policy that a process's minimum integrity is 5, its maximum is 15, and the default effective label is 10. The process will run at 10 until it chooses to change label, perhaps due to the user using &man.setpmac.8;, which will be constrained by Biba to the configured range. After any change to login.conf, the login class capability database must be rebuilt using cap_mkdb. Many sites have a large number of users requiring several different user classes. In depth planning is required as this may get extremely difficult to manage. Network Interfaces and Label Settings Labels may be set on network interfaces to help control the flow of data across the network. Policies using network interface labels function in the same way that policies function with respect to objects. Users at high settings in biba, for example, will not be permitted to access network interfaces with a label of low. may be passed to ifconfig when setting the MAC label on network interfaces. For example: &prompt.root; ifconfig bge0 maclabel biba/equal will set the MAC label of biba/equal on the &man.bge.4; interface. When using a setting similar to biba/high(low-high), the entire label should be quoted to prevent an error from being returned. Each policy module which supports labeling has a tunable which may be used to disable the MAC label on network interfaces. Setting the label to will have a similar effect. Review the output of sysctl, the policy manual pages, and the information in this chapter for more information on those tunables. Singlelabel or Multilabel? By default, the system will use . For the administrator, there are several differences which offer pros and cons to the flexibility in the system's security model. A security policy which uses only permits one label, such as biba/high, to be used for each subject or object. This provides lower administration overhead, but decreases the flexibility of policies which support labeling. permits each subject or object to have its own independent MAC label. The decision to use or is only required for the policies which implement the labeling feature, including the Biba, Lomac, and MLS policies. In many cases, may not be needed. Consider the following situation and security model: &os; web-server using the MAC framework and a mix of the various policies. This machine only requires one label, biba/high, for everything in the system. This file system would not require as a single label will always be in effect. But, this machine will be a web server and should have the web server run at biba/low to prevent write up capabilities. The server could use a separate partition set at biba/low for most if not all of its runtime state. If any of the non-labeling policies are to be used, would not be required. These include the seeotheruids, portacl and partition policies. Using with a partition and establishing a security model based on functionality could increase administrative overhead as everything in the file system has a label. This includes directories, files, and even device nodes. The following command will set on the file systems to have multiple labels. This may only be done in single user mode and is not a requirement for the swap file system: &prompt.root; tunefs -l enable / Some users have experienced problems with setting the flag on the root partition. If this is the case, please review the of this chapter. Planning the Security Configuration Whenever a new technology is implemented, a planning phase is recommended. During the planning stages, an administrator should consider the implementation requirements and the implementation goals. For MAC installations, these include: How to classify information and resources available on the target systems. Which information or resources to restrict access to along with the type of restrictions that should be applied. Which MAC module or modules will be required to achieve this goal. Good planning helps to ensure a trouble-free and efficient trusted system implementation. A trial run of the trusted system and its configuration should occur before a MAC implementation is used on production systems. The idea of just letting loose on a system with MAC is like setting up for failure. Different environments have different needs and requirements. Establishing an in depth and complete security profile will decrease the need of changes once the system goes live. The rest of this chapter covers the available modules, describes their use and configuration, and in some cases, provides insight on applicable situations. For instance, a web server might use the &man.mac.biba.4; and &man.mac.bsdextended.4; policies. In the case of a machine with few local users, &man.mac.partition.4; might be a good choice. Module Configuration Beginning with &os; 8.0, the default &os; kernel includes options MAC. This means that every module included with the MAC framework may be loaded as a run-time kernel module. The recommended method is to add the module name to /boot/loader.conf so that it will load during boot. Each module also provides a kernel option for those administrators who choose to compile their own custom kernel. Some modules support the use of labeling, which is controlling access by enforcing a label such as this is allowed and this is not. A label configuration file may control how files may be accessed, network communication can be exchanged, and more. The previous section showed how the flag could be set on file systems to enable per-file or per-partition access control. A single label configuration enforces only one label across the system, that is why the tunefs option is called . - The &man.mac.seeotheruids.4; Module + The MAC See Other UIDs Policy MAC See Other UIDs Policy Module name: mac_seeotheruids.ko Kernel configuration line: options MAC_SEEOTHERUIDS Boot option: mac_seeotheruids_load="YES" The &man.mac.seeotheruids.4; module mimics and extends the security.bsd.see_other_uids and security.bsd.see_other_gids sysctl tunables. This option does not require any labels to be set before configuration and can operate transparently with the other modules. After loading the module, the following sysctl tunables may be used to control the features: security.mac.seeotheruids.enabled enables the module and uses the default settings which deny users the ability to view processes and sockets owned by other users. security.mac.seeotheruids.specificgid_enabled allows certain groups to be exempt from this policy. To exempt specific groups from this policy, use the security.mac.seeotheruids.specificgid=XXX sysctl tunable. Replace XXX with the numeric group ID to be exempted. security.mac.seeotheruids.primarygroup_enabled is used to exempt specific primary groups from this policy. When using this tunable, security.mac.seeotheruids.specificgid_enabled may not be set. - The &man.mac.bsdextended.4; Module + The MAC BSD Extended Policy MAC File System Firewall Policy Module name: mac_bsdextended.ko Kernel configuration line: options MAC_BSDEXTENDED Boot option: mac_bsdextended_load="YES" The &man.mac.bsdextended.4; module enforces the file system firewall. This module's policy provides an extension to the standard file system permissions model, permitting an administrator to create a firewall-like ruleset to protect files, utilities, and directories in the file system hierarchy. When access to a file system object is attempted, the list of rules is iterated until either a matching rule is located or the end is reached. This behavior may be changed by the use of a &man.sysctl.8; parameter, security.mac.bsdextended.firstmatch_enabled. Similar to other firewall modules in &os;, a file containing the access control rules can be created and read by the system at boot time using an &man.rc.conf.5; variable. The rule list may be entered using &man.ugidfw.8; which has a syntax similar to &man.ipfw.8;. More tools can be written by using the functions in the &man.libugidfw.3; library. Extreme caution should be taken when working with this module as incorrect use could block access to certain parts of the file system. Examples After the &man.mac.bsdextended.4; module has been loaded, the following command may be used to list the current rule configuration: &prompt.root; ugidfw list 0 slots, 0 rules By default, no rules are defined and everything is completely accessible. To create a rule which will block all access by users but leave root unaffected, run the following command: &prompt.root; ugidfw add subject not uid root new object not uid root mode n This is a very bad idea as it will block all users from issuing even the most simple commands, such as ls. The next example will block user1 any and all access, including directory listings, to user2's home directory: &prompt.root; ugidfw set 2 subject uid user1 object uid user2 mode n &prompt.root; ugidfw set 3 subject uid user1 object gid user2 mode n Instead of user1, could be used. This enforces the same access restrictions for all users instead of just one user. The root user is unaffected by these changes. For more information, refer to &man.mac.bsdextended.4; and &man.ugidfw.8; - The &man.mac.ifoff.4; Module + The MAC Interface Silencing Policy MAC Interface Silencing Policy Module name: mac_ifoff.ko Kernel configuration line: options MAC_IFOFF Boot option: mac_ifoff_load="YES" The &man.mac.ifoff.4; module exists solely to disable network interfaces on the fly and keep network interfaces from being brought up during system boot. It does not require any labels to be set up on the system, nor does it depend on other MAC modules. Most of this module's control is performed through the sysctl tunables listed below. security.mac.ifoff.lo_enabled enables or disables all traffic on the loopback (&man.lo.4;) interface. security.mac.ifoff.bpfrecv_enabled enables or disables all traffic on the Berkeley Packet Filter interface (&man.bpf.4;) security.mac.ifoff.other_enabled enables or disables traffic on all other interfaces. One of the most common uses of &man.mac.ifoff.4; is network monitoring in an environment where network traffic should not be permitted during the boot sequence. Another suggested use would be to write a script which uses security/aide to automatically block network traffic if it finds new or altered files in protected directories. - The &man.mac.portacl.4; Module + The MAC Port Access Control List Policy MAC Port Access Control List Policy Module name: mac_portacl.ko Kernel configuration line: MAC_PORTACL Boot option: mac_portacl_load="YES" The &man.mac.portacl.4; module is used to limit binding to local TCP and UDP ports using a variety of sysctl variables. &man.mac.portacl.4; makes it possible to allow non-root users to bind to specified privileged ports below 1024. Once loaded, this module enables the MAC policy on all sockets. The following tunables are available: security.mac.portacl.enabled enables or disables the policy completely. security.mac.portacl.port_high sets the highest port number that &man.mac.portacl.4; protects. security.mac.portacl.suser_exempt, when set to a non-zero value, exempts the root user from this policy. security.mac.portacl.rules specifies the mac_portacl policy, which is a text string of the form: rule[,rule,...] with as many rules as needed. Each rule is of the form: idtype:id:protocol:port. The idtype parameter can be uid or gid and is used to interpret the id parameter as either a user id or group id, respectively. The protocol parameter is used to determine if the rule should apply to TCP or UDP by setting the parameter to tcp or udp. The final port parameter is the port number to allow the specified user or group to bind to. Since the ruleset is interpreted directly by the kernel, only numeric values can be used for the user ID, group ID, and port parameters. Names cannot be used for users, groups, or services. By default, ports below 1024 can only be used by or bound to privileged processes, which run as root. For &man.mac.portacl.4; to allow non-privileged processes to bind to ports below 1024, this restriction has to be disabled by setting the &man.sysctl.8; variables net.inet.ip.portrange.reservedlow and net.inet.ip.portrange.reservedhigh to zero: &prompt.root; sysctl security.mac.portacl.port_high=1023 &prompt.root; sysctl net.inet.ip.portrange.reservedlow=0 net.inet.ip.portrange.reservedhigh=0 See the examples below or refer to &man.mac.portacl.4; for further information. Examples Since the root user should not be crippled by this policy, this example starts by setting the security.mac.portacl.suser_exempt to a non-zero value. &prompt.root; sysctl security.mac.portacl.suser_exempt=1 Next, allow the user with UID 80 to bind to port 80. This allows the www user to run a web server without ever having root privilege. &prompt.root; sysctl security.mac.portacl.rules=uid:80:tcp:80 The next example permits the user with the UID of 1001 to bind to the TCP ports 110 (pop3) and 995 (pop3s). This permits this user to start a server that accepts connections on ports 110 and 995. &prompt.root; sysctl security.mac.portacl.rules=uid:1001:tcp:110,uid:1001:tcp:995 - The &man.mac.partition.4; Module + The MAC Partition Policy MAC Process Partition Policy Module name: mac_partition.ko Kernel configuration line: options MAC_PARTITION Boot option: mac_partition_load="YES" The &man.mac.partition.4; policy will drop processes into specific partitions based on their MAC label. This module should be added to &man.loader.conf.5; so that it loads and enables the policy at system boot. Most configuration for this policy is done using &man.setpmac.8;. One sysctl tunable is available for this policy: security.mac.partition.enabled enables the enforcement of MAC process partitions. When this policy is enabled, users will only be permitted to see their processes, and any others within their partition, but will not be permitted to work with utilities outside the scope of this partition. For instance, a user in the insecure class will not be permitted to access top as well as many other commands that must spawn a process. To set or drop utilities into a partition label, use the setpmac utility: &prompt.root; setpmac partition/13 top This example adds top to the label set on users in the insecure class. All processes spawned by users in the insecure class will stay in the partition/13 label. Examples The following command will display the partition label and the process list: &prompt.root; ps Zax This command will display another user's process partition label and that user's currently running processes: &prompt.root; ps -ZU trhodes Users can see processes in root's label unless the &man.mac.seeotheruids.4; policy is loaded. A really crafty implementation could have all of the services disabled in /etc/rc.conf and started by a script that starts them with the proper labeling set. The following policies support integer settings in place of the three default labels offered. These options, including their limitations, are further explained in the module manual pages. The MAC Multi-Level Security Module MAC Multi-Level Security Policy Module name: mac_mls.ko Kernel configuration line: options MAC_MLS Boot option: mac_mls_load="YES" The &man.mac.mls.4; policy controls access between subjects and objects in the system by enforcing a strict information flow policy. In MLS environments, a clearance level is set in the label of each subject or object, along with compartments. Since these clearance or sensibility levels can reach numbers greater than several thousand; it would be a daunting task for any system administrator to thoroughly configure each subject or object. Thankfully, three instant labels are included in this policy. These labels are mls/low, mls/equal and mls/high. Since these labels are described in depth in the manual page, they will only get a brief description here: The mls/low label contains a low configuration which permits it to be dominated by all other objects. Anything labeled with mls/low will have a low clearance level and not be permitted to access information of a higher level. This label also prevents objects of a higher clearance level from writing or passing information on to them. The mls/equal label should be placed on objects considered to be exempt from the policy. The mls/high label is the highest level of clearance possible. Objects assigned this label will hold dominance over all other objects in the system; however, they will not permit the leaking of information to objects of a lower class. MLS provides: A hierarchical security level with a set of non hierarchical categories. Fixed rules of no read up, no write down. This means that a subject can have read access to objects on its own level or below, but not above. Similarly, a subject can have write access to objects on its own level or above but not beneath. Secrecy, or the prevention of inappropriate disclosure of data. A basis for the design of systems that concurrently handle data at multiple sensitivity levels without leaking information between secret and confidential. The following sysctl tunables are available for the configuration of special services and interfaces: security.mac.mls.enabled is used to enable or disable the MLS policy. security.mac.mls.ptys_equal labels all &man.pty.4; devices as mls/equal during creation. security.mac.mls.revocation_enabled revokes access to objects after their label changes to a label of a lower grade. security.mac.mls.max_compartments sets the maximum number of compartment levels allowed on a system. To manipulate the MLS labels, use &man.setfmac.8;. To assign a label to an object, issue the following command: &prompt.root; setfmac mls/5 test To get the MLS label for the file test, issue the following command: &prompt.root; getfmac test Another approach is to create a master policy file in /etc/ which specifies the MLS policy information and to feed that file to setfmac. This method will be explained after all policies are covered. Planning Mandatory Sensitivity When using the MLS policy module, an administrator plans to control the flow of sensitive information. The default block read up block write down sets everything to a low state. Everything is accessible and an administrator slowly augments the confidentiality of the information during the configuration stage;. Beyond the three basic label options, an administrator may group users and groups as required to block the information flow between them. It might be easier to look at the information in clearance levels using descriptive words, such as classifications of Confidential, Secret, and Top Secret. Some administrators instead create different groups based on project levels. Regardless of the classification method, a well thought out plan must exist before implementing such a restrictive policy. Some example situations for the MLS policy module include an e-commerce web server, a file server holding critical company information, and financial institution environments. The MAC Biba Module MAC Biba Integrity Policy Module name: mac_biba.ko Kernel configuration line: options MAC_BIBA Boot option: mac_biba_load="YES" The &man.mac.biba.4; module loads the MAC Biba policy. This policy is similar to the MLS policy with the exception that the rules for information flow are slightly reversed. This is to prevent the downward flow of sensitive information whereas the MLS policy prevents the upward flow of sensitive information. Much of this section can apply to both policies. In Biba environments, an integrity label is set on each subject or object. These labels are made up of hierarchical grades and non-hierarchical components. As an grade ascends, so does its integrity. Supported labels are biba/low, biba/equal, and biba/high; as explained below: The biba/low label is considered the lowest integrity an object or subject may have. Setting this on objects or subjects will block their write access to objects or subjects marked high. They still have read access though. The biba/equal label should only be placed on objects considered to be exempt from the policy. The biba/high label will permit writing to objects set at a lower label, but not permit reading that object. It is recommended that this label be placed on objects that affect the integrity of the entire system. Biba provides: Hierarchical integrity level with a set of non hierarchical integrity categories. Fixed rules are no write up, no read down, the opposite of MLS. A subject can have write access to objects on its own level or below, but not above. Similarly, a subject can have read access to objects on its own level or above, but not below. Integrity by preventing inappropriate modification of data. Integrity levels instead of MLS sensitivity levels. The following sysctl tunables can be used to manipulate the Biba policy: security.mac.biba.enabled is used to enable or disable enforcement of the Biba policy on the target machine. security.mac.biba.ptys_equal is used to disable the Biba policy on &man.pty.4; devices. security.mac.biba.revocation_enabled forces the revocation of access to objects if the label is changed to dominate the subject. To access the Biba policy setting on system objects, use setfmac and getfmac: &prompt.root; setfmac biba/low test &prompt.root; getfmac test test: biba/low Planning Mandatory Integrity Integrity, which is different from sensitivity, guarantees that the information will never be manipulated by untrusted parties. This includes information passed between subjects, objects, and both. It ensures that users will only be able to modify or access information they explicitly need to. The &man.mac.biba.4; security policy module permits an administrator to address which files and programs a user may see and invoke while assuring that the programs and files are free from threats and trusted by the system for that user. During the initial planning phase, an administrator must be prepared to partition users into grades, levels, and areas. Users will be blocked access not only to data but to programs and utilities both before and after they start. The system will default to a high label once this policy module is enabled, and it is up to the administrator to configure the different grades and levels for users. Instead of using clearance levels, a good planning method could include topics. For instance, only allow developers modification access to the source code repository, source code compiler, and other development utilities. Other users would be grouped into other categories such as testers, designers, or end users and would only be permitted read access. A lower integrity subject is unable to write to a higher integrity subject and a higher integrity subject cannot observe or read a lower integrity object. Setting a label at the lowest possible grade could make it inaccessible to subjects. Some prospective environments for this security policy module would include a constrained web server, a development and test machine, and a source code repository. A less useful implementation would be a personal workstation, a machine used as a router, or a network firewall. The MAC LOMAC Module MAC LOMAC Module name: mac_lomac.ko Kernel configuration line: options MAC_LOMAC Boot option: mac_lomac_load="YES" Unlike the MAC Biba policy, the &man.mac.lomac.4; policy permits access to lower integrity objects only after decreasing the integrity level to not disrupt any integrity rules. The MAC version of the Low-watermark integrity policy works almost identically to Biba, but with the exception of using floating labels to support subject demotion via an auxiliary grade compartment. This secondary compartment takes the form [auxgrade]. When assigning a LOMAC policy with an auxiliary grade, use the syntax lomac/10[2] where the number two (2) is the auxiliary grade. The MAC LOMAC policy relies on the ubiquitous labeling of all system objects with integrity labels, permitting subjects to read from low integrity objects and then downgrading the label on the subject to prevent future writes to high integrity objects using [auxgrade]. The policy may provide for greater compatibility and require less initial configuration than Biba. Examples Like the Biba and MLS policies, setfmac and setpmac are used to place labels on system objects: &prompt.root; setfmac /usr/home/trhodes lomac/high[low] &prompt.root; getfmac /usr/home/trhodes lomac/high[low] The auxiliary grade low is a feature provided only by the MAC LOMAC policy. Nagios in a MAC Jail Nagios in a MAC Jail The following demonstration implements a secure environment using various MAC modules with properly configured policies. This is only a test as implementing a policy and ignoring it could be disastrous in a production environment. Before beginning this process, must be set on each file system as not doing so will result in errors. This example assumes that net-mngt/nagios-plugins, net-mngt/nagios, and www/apache22 are all installed, configured, and working correctly. Create an Insecure User Class Begin the procedure by adding the following user class to /etc/login.conf: insecure:\ :copyright=/etc/COPYRIGHT:\ :welcome=/etc/motd:\ :setenv=MAIL=/var/mail/$,BLOCKSIZE=K:\ :path=~/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin :manpath=/usr/share/man /usr/local/man:\ :nologin=/usr/sbin/nologin:\ :cputime=1h30m:\ :datasize=8M:\ :vmemoryuse=100M:\ :stacksize=2M:\ :memorylocked=4M:\ :memoryuse=8M:\ :filesize=8M:\ :coredumpsize=8M:\ :openfiles=24:\ :maxproc=32:\ :priority=0:\ :requirehome:\ :passwordtime=91d:\ :umask=022:\ :ignoretime@:\ :label=biba/10(10-10): Add the following line to the default user class: :label=biba/high: Next, issue the following command to rebuild the database: &prompt.root; cap_mkdb /etc/login.conf Boot Configuration Add the following lines to /boot/loader.conf: mac_biba_load="YES" mac_seeotheruids_load="YES" Configure Users Set the root user to the default class using: &prompt.root; pw usermod root -L default All user accounts that are not root or system users will now require a login class. The login class is required otherwise users will be refused access to common commands such as &man.vi.1;. The following sh script should do the trick: &prompt.root; for x in `awk -F: '($3 >= 1001) && ($3 != 65534) { print $1 }' \ /etc/passwd`; do pw usermod $x -L default; done; Drop the nagios and www users into the insecure class: &prompt.root; pw usermod nagios -L insecure &prompt.root; pw usermod www -L insecure Create the Contexts File A contexts file should now be created as /etc/policy.contexts. # This is the default BIBA policy for this system. # System: /var/run biba/equal /var/run/* biba/equal /dev biba/equal /dev/* biba/equal /var biba/equal /var/spool biba/equal /var/spool/* biba/equal /var/log biba/equal /var/log/* biba/equal /tmp biba/equal /tmp/* biba/equal /var/tmp biba/equal /var/tmp/* biba/equal /var/spool/mqueue biba/equal /var/spool/clientmqueue biba/equal # For Nagios: /usr/local/etc/nagios /usr/local/etc/nagios/* biba/10 /var/spool/nagios biba/10 /var/spool/nagios/* biba/10 # For apache /usr/local/etc/apache biba/10 /usr/local/etc/apache/* biba/10 This policy enforces security by setting restrictions on the flow of information. In this specific configuration, users, including root, should never be allowed to access Nagios. Configuration files and processes that are a part of Nagios will be completely self contained or jailed. This file will be read by the system by issuing the following command: &prompt.root; setfsmac -ef /etc/policy.contexts / &prompt.root; setfsmac -ef /etc/policy.contexts / The above file system layout will differ depending upon the environment and must be run on every file system. /etc/mac.conf requires the following modifications in the main section: default_labels file ?biba default_labels ifnet ?biba default_labels process ?biba default_labels socket ?biba Enable Networking Add the following line to /boot/loader.conf: security.mac.biba.trust_all_interfaces=1 And the following to the network card configuration stored in rc.conf. If the primary Internet configuration is done via DHCP, this may need to be configured manually after every system boot: maclabel biba/equal Testing the Configuration MAC Configuration Testing Ensure that the web server and Nagios will not be started on system initialization and reboot. Ensure the root user cannot access any of the files in the Nagios configuration directory. If root can issue an &man.ls.1; command on /var/spool/nagios, something is wrong. Otherwise a permission denied error should be returned. If all seems well, Nagios, Apache, and Sendmail can now be started: &prompt.root; cd /etc/mail && make stop && \ setpmac biba/equal make start && setpmac biba/10\(10-10\) apachectl start && \ setpmac biba/10\(10-10\) /usr/local/etc/rc.d/nagios.sh forcestart Double check to ensure that everything is working properly. If not, check the log files for error messages. Use &man.sysctl.8; to disable the &man.mac.biba.4; security policy module enforcement and try starting everything again as usual. The root user can still change the security enforcement and edit its configuration files. The following command will permit the degradation of the security policy to a lower grade for a newly spawned shell: &prompt.root; setpmac biba/10 csh To block this from happening, force the user into a range using &man.login.conf.5;. If &man.setpmac.8; attempts to run a command outside of the compartment's range, an error will be returned and the command will not be executed. In this case, set root to biba/high(high-high). User Lock Down This example considers a relatively small storage system with fewer than fifty users. Users will have login capabilities, and be permitted to store data and access resources. For this scenario, the &man.mac.bsdextended.4; and &man.mac.seeotheruids.4; policy modules could co-exist and block access to system objects while hiding user processes. Begin by adding the following line to /boot/loader.conf: mac_seeotheruids_load="YES" The &man.mac.bsdextended.4; security policy module may be activated by adding this line to /etc/rc.conf: ugidfw_enable="YES" Default rules stored in /etc/rc.bsdextended will be loaded at system initialization. However, the default entries may need modification. Since this machine is expected only to service users, everything may be left commented out except the last two lines in order to force the loading of user owned system objects by default. Add the required users to this machine and reboot. For testing purposes, try logging in as a different user across two consoles. Run ps aux to see if processes of other users are visible. Verify that running &man.ls.1; on another user's home directory fails. Do not try to test with the root user unless the specific sysctls have been modified to block super user access. When a new user is added, their &man.mac.bsdextended.4; rule will not be in the ruleset list. To update the ruleset quickly, unload the security policy module and reload it again using &man.kldunload.8; and &man.kldload.8;. Troubleshooting the MAC Framework MAC Troubleshooting This section discusses common configuration issues. - - <option>multilabel</option> cannot be enabled on - <filename>/</filename> - - The flag does not stay - enabled on my root (/) partition! - + + + The flag does not stay + enabled on my root (/) partition! - The following steps may resolve this transient - error: + The following steps may resolve this transient + error: - - - Edit /etc/fstab and set the root - partition to for read-only. - + + + Edit /etc/fstab and set the root + partition to for read-only. + - - Reboot into single user mode. - + + Reboot into single user mode. + - - Run tunefs - + on /. + + + + Reboot the system. + + + + Run mount + / and change the + back to in + /etc/fstab and reboot the system + again. + + + + Double-check the output from + mount to ensure that + has been properly set on the + root file system. + + + - - Xorg Server Will Not Start After - <acronym>MAC</acronym> - - After establishing a secure environment with - MAC, I am no longer able to start - Xorg! - - This could be caused by the MAC - partition policy or by a mislabeling in - one of the MAC labeling policies. To - debug, try the following: - - - - Check the error message; if the user is in the - insecure class, the - partition policy may be the culprit. - Try setting the user's class back to the - default class and rebuild the database - with cap_mkdb. If this does not - alleviate the problem, go to step two. - - - - Double-check the label policies. Ensure that the - policies are set correctly for the user, the Xorg - application, and the /dev entries. - - - - If neither of these resolve the problem, send the - error message and a description of the environment to - the &a.questions; mailing list. - - - + + After establishing a secure environment with + MAC, I am no longer able to start + Xorg! + + This could be caused by the MAC + partition policy or by a mislabeling in + one of the MAC labeling policies. To + debug, try the following: + + + + Check the error message; if the user is in the + insecure class, the + partition policy may be the culprit. + Try setting the user's class back to the + default class and rebuild the database + with cap_mkdb. If this does not + alleviate the problem, go to step two. + + + + Double-check the label policies. Ensure that the + policies are set correctly for the user, the Xorg + application, and the /dev entries. + + + + If neither of these resolve the problem, send the + error message and a description of the environment to + the &a.questions; mailing list. + + + - - Error: &man..secure.path.3; cannot stat - <filename>.login_conf</filename> + + The error: _secure_path: unable to stat + .login_conf shows up. - When a user attempts to switch from the - root user to another user in the system, - the error message _secure_path: unable to state + When a user attempts to switch from the + root user to another user in the system, + the error message _secure_path: unable to stat .login_conf appears. - This message is usually shown when the user has a higher - label setting than that of the user they are attempting to - become. For instance, joe has a default - label of . The - root user, who has a label of - , cannot view - joe's home directory. This will happen - whether or not root has used - su to become joe as - the Biba integrity model will not permit - root to view objects set at a lower - integrity level. - + This message is usually shown when the user has a higher + label setting than that of the user they are attempting to + become. For instance, joe has a default + label of . The + root user, who has a label of + , cannot view + joe's home directory. This will happen + whether or not root has used + su to become joe as + the Biba integrity model will not permit + root to view objects set at a lower + integrity level. + - - The <username>root</username> username is broken! + + The system no longer recognizes the + root user. - In normal or even single user mode, the - root is not recognized, - whoami returns 0 (zero), and - su returns who are + In normal or even single user mode, the + root is not recognized, + whoami returns 0 (zero), and + su returns who are you?. - This can happen if a labeling policy has been disabled, - either by a &man.sysctl.8; or the policy module was unloaded. - If the policy is disabled, the login capabilities database - needs to be reconfigured with removed. - Double check login.conf to ensure that - all options have been removed and - rebuild the database with cap_mkdb. - - This may also happen if a policy restricts access to - master.passwd. This is usually caused by - an administrator altering the file under a label which - conflicts with the general policy being used by the system. - In these cases, the user information would be read by the - system and access would be blocked as the file has inherited - the new label. Disable the policy using &man.sysctl.8; and - everything should return to normal. - + This can happen if a labeling policy has been disabled, + either by a &man.sysctl.8; or the policy module was unloaded. + If the policy is disabled, the login capabilities database + needs to be reconfigured with removed. + Double check login.conf to ensure that + all options have been removed and + rebuild the database with cap_mkdb. + + This may also happen if a policy restricts access to + master.passwd. This is usually caused by + an administrator altering the file under a label which + conflicts with the general policy being used by the system. + In these cases, the user information would be read by the + system and access would be blocked as the file has inherited + the new label. Disable the policy using &man.sysctl.8; and + everything should return to normal. + + diff --git a/en_US.ISO8859-1/books/handbook/mail/chapter.xml b/en_US.ISO8859-1/books/handbook/mail/chapter.xml index eb088d55f3..308d952042 100644 --- a/en_US.ISO8859-1/books/handbook/mail/chapter.xml +++ b/en_US.ISO8859-1/books/handbook/mail/chapter.xml @@ -1,2185 +1,2103 @@ Bill Lloyd Original work by Jim Mock Rewritten by Electronic Mail Synopsis email Electronic Mail, better known as email, is one of the most widely used forms of communication today. This chapter provides a basic introduction to running a mail server on &os;, as well as an introduction to sending and - receiving email using &os;; however, it is not a complete - reference and in fact many important considerations are omitted. - For more complete coverage of the subject, the reader is - referred to the many excellent books listed in + receiving email using &os;. + For more complete coverage of this subject, + refer to the books listed in . After reading this chapter, you will know: - What software components are involved in sending and + Which software components are involved in sending and receiving electronic mail. Where basic sendmail - configuration files are located in FreeBSD. + configuration files are located in &os;. - The difference between remote and - local mailboxes. + The difference between remote and local + mailboxes. - How to block spammers from illegally using your mail + How to block spammers from illegally using a mail server as a relay. How to install and configure an alternate Mail Transfer - Agent on your system, replacing + Agent, replacing sendmail. How to troubleshoot common mail server problems. How to set up the system to send mail only. How to use mail with a dialup connection. - How to configure SMTP Authentication for added + How to configure SMTP authentication for added security. How to install and use a Mail User Agent, such as - mutt to send and receive + mutt, to send and receive email. - How to download your mail from a remote + How to download mail from a remote POP or IMAP server. How to automatically apply filters and rules to incoming email. Before reading this chapter, you should: - Properly set up your network connection - (). + Properly set up a network connection (). - Properly set up the DNS information for your mail host - (). + Properly set up the DNS information + for a mail host (). Know how to install additional third-party software (). Using Electronic Mail POP IMAP DNS - There are five major parts involved in an email exchange. - They are: the user program, - the server daemon, DNS, a - remote or local mailbox, and of course, the mailhost itself. + There are five major parts involved in an email exchange: + the Mail User Agent + MUA>, the + Mail Transfer AgentMTA, DNS, a remote or local mailbox, and + the mail host. - The User Program + The Mail User Agent This includes command line programs such as mutt, alpine, elm, and - mail, and GUI - programs such as balsa, - xfmail to name a few, and something - more sophisticated like a WWW browser. These - programs simply pass off the email transactions to the local - mailhost, - either by calling one of the server - daemons available, or delivering it over - TCP. + mail, GUI programs such + as balsa or + xfmail, and web mail programs + which can be accessed from a web browser. User programs pass + the email transactions to the local mail host, either + by a MTA, or by + delivering it over TCP. - Mailhost Server Daemon + The Mail Transfer Agent mail server daemons - sendmail + Sendmail mail server daemons - postfix + Postfix mail server daemons qmail mail server daemons - exim + Exim - &os; ships with sendmail by - default, but also support numerous other mail server daemons, - just some of which include: + &os; ships with Sendmail as the + default MTA, but it also supports numerous + other mail server daemons, including: - exim; + Exim; - postfix; + Postfix; qmail. - The server daemon usually has two functions—it is - responsible for receiving incoming mail as well as delivering - outgoing mail. It is not responsible - for the collection of mail using protocols such as - POP or IMAP to read - your email, nor does it allow connecting to local - mbox or Maildir mailboxes. You may - require an additional daemon for that. + The MTA usually has two functions. It + is responsible for receiving incoming mail as well as + delivering outgoing mail. It is not + responsible for the collection of mail using protocols such as + POP or IMAP, nor does it + allow connecting to local mbox or Maildir + mailboxes. An additional daemon may be required for + these functions. - Older versions of sendmail - have some serious security issues which may result in an - attacker gaining local and/or remote access to your machine. - Make sure that you are running a current version to avoid - these problems. Optionally, install an alternative - MTA from the &os; - Ports Collection. + Older versions of Sendmail + contain serious security issues which may result in an + attacker gaining local or remote access to the system. + Run a current version to &os; to avoid these problems. + Optionally, install an alternative MTA + from the &os; Ports + Collection. Email and DNS - The Domain Name System (DNS) and its daemon - named play a large role in the delivery - of email. In order to deliver mail from your site to another, - the server daemon will look up the remote site in the DNS - to determine the host that will receive mail for the - destination. This process also occurs when mail is sent from - a remote host to your mail server. + The Domain Name System (DNS) and its + daemon named play a large role in the + delivery of email. In order to deliver mail from one site to + another, the MTA will look up the remote + site in DNS to determine which host will + receive mail for the destination. This process also occurs + when mail is sent from a remote host to the + MTA. MX record DNS is responsible for mapping hostnames to IP addresses, as well as for storing information - specific to mail delivery, known as MX records. The MX (Mail - eXchanger) record specifies which host, or hosts, will receive - mail for a particular domain. If you do not have an MX record - for your hostname or domain, the mail will be delivered - directly to your host provided you have an A record pointing - your hostname to your IP address. - - You may view the MX records for any domain by using the - &man.host.1; command, as seen in the example below: + specific to mail delivery, known as Mail eXchanger + MX records. The MX + record specifies which host, or hosts, will receive mail for a + particular domain. If there is no MX + record for the hostname or domain, the mail will be delivered + directly to the host, provided there is an + A record pointing the hostname to the IP + address. + + To view the MX records for a domain, + specify the type of record using &man.host.1;, as seen in the + example below: &prompt.user; host -t mx FreeBSD.org -FreeBSD.org mail is handled (pri=10) by mx1.FreeBSD.org +FreeBSD.org mail is handled by 10 mx1.FreeBSD.org Receiving Mail email receiving - Receiving mail for your domain is done by the mail host. - It will collect all mail sent to your domain and store it - either in mbox (the default method for - storing mail) or Maildir format, depending on your - configuration. Once mail has been stored, it may either be - read locally using applications such as &man.mail.1; or - mutt, or remotely accessed and - collected using protocols such as POP or - IMAP. This means that should you only - wish to read mail locally, you are not required to install - a POP or IMAP - server. + Receiving mail for a domain is done by the mail host. + It will collect all mail sent to the domain and store it + either in the default mbox or the + alternative Maildir format, depending on the configuration. + Once mail has been stored, it may either be read locally using + a MUA, or remotely accessed and collected + using protocols such as POP or + IMAP. In order to read mail locally, + a POP or IMAP server + does not need to be installed. - Accessing remote mailboxes using <acronym>POP</acronym> + <title>Accessing Remote Mailboxes Using <acronym>POP</acronym> and <acronym>IMAP</acronym> POP IMAP - In order to access mailboxes remotely, you are required - to have access to a POP or - IMAP server. These protocols allow users - to connect to their mailboxes from remote locations with - ease. Though both POP and - IMAP allow users to remotely access - mailboxes, IMAP offers many advantages, - some of which are: + To access mailboxes remotely, access to a + POP or IMAP server is + required. These protocols allow users to connect to their + mailboxes from remote locations. Though both + POP and IMAP allow + users to remotely access mailboxes, IMAP + offers many advantages, including: IMAP can store messages on a remote server as well as fetch them. IMAP supports concurrent updates. - IMAP can be extremely useful over + IMAP can be useful over low-speed links as it allows users to fetch the - structure of messages without downloading them; it can + structure of messages without downloading them. It can also perform tasks such as searching on the server in order to minimize data transfer between clients and servers. In order to install a POP or IMAP server, the following steps should be performed: - Choose an IMAP or - POP server that best suits your - needs. The following POP and - IMAP servers are well known and serve - as some good examples: + Use the Ports Collection to install an + IMAP or POP + server. The following POP and + IMAP servers are well known: - qpopper; + mail/qpopper - teapop; + mail/teapop - imap-uw; + mail/imap-uw - courier-imap; + mail/courier-imap - dovecot; + mail/dovecot2 - Install the POP or - IMAP daemon of your choosing from - the ports collection. - - - - Where required, modify - /etc/inetd.conf to load the - POP or IMAP - server. + Where required, use the startup script that came + with the application to load the POP + or IMAP server. Those programs will + also provide a variable which can be added to + /etc/rc.conf to automate the + startup of the application's daemon whenever the system + boots. It should be noted that both POP and IMAP transmit information, - including username and password credentials in clear-text. - This means that if you wish to secure the transmission - of information across these protocols, you should consider - tunneling sessions over &man.ssh.1; or using SSL. - Tunneling sessions is described in - and SSL is - described in . + including username and password credentials, in + clear-text. To secure the transmission of information + across these protocols, consider tunneling sessions over + &man.ssh.1; () or + using SSL (). Accessing Local Mailboxes - Mailboxes may be accessed locally by directly utilizing - MUAs on the server on which the mailbox - resides. This can be done using applications such as - mutt or &man.mail.1;. + Mailboxes may be accessed locally by directly using an + MUA on the server on which the mailbox + resides. This can be done using a built-in application + such as &man.mail.1; or by installing a + MUA from the Ports Collection.. The Mail Host mail host - The mail host is the name given to a server that is - responsible for delivering and receiving mail for your host, - and possibly your network. + The mail host is a server that is responsible for + delivering and receiving mail for a host, or a network. Christopher Shumway Contributed by - <application>sendmail</application> Configuration + <application>Sendmail</application> Configuration - sendmail + Sendmail - &man.sendmail.8; is the default Mail Transfer Agent (MTA) - in FreeBSD. sendmail's job is to - accept mail from Mail User Agents (MUA) and - deliver it to the appropriate mailer as defined by its - configuration file. sendmail can - also accept network connections and deliver mail to local - mailboxes or deliver it to another program. + &man.sendmail.8; is the default MTA + which is installed with &os;. + Sendmail accepts mail from + MUAs and delivers it to the appropriate + mailer as defined by its configuration file. + Sendmail can also accept network + connections and deliver mail to local mailboxes or to another + program. - sendmail uses the following - configuration files: + Sendmail uses the following + configuration files. This section describes these files in more + detail. /etc/mail/access /etc/mail/aliases /etc/mail/local-host-names /etc/mail/mailer.conf /etc/mail/mailertable /etc/mail/sendmail.cf /etc/mail/virtusertable Filename Function /etc/mail/access - sendmail access database - file + Sendmail access database + file. /etc/mail/aliases Mailbox aliases /etc/mail/local-host-names - Lists of hosts sendmail - accepts mail for + Lists of hosts Sendmail + accepts mail for. /etc/mail/mailer.conf - Mailer program configuration + Mailer program configuration. /etc/mail/mailertable - Mailer delivery table + Mailer delivery table. /etc/mail/sendmail.cf - sendmail master - configuration file + Sendmail master + configuration file. /etc/mail/virtusertable - Virtual users and domain tables + Virtual users and domain tables. <filename>/etc/mail/access</filename> - The access database defines what host(s) or IP addresses + This database defines which host(s) or IP addresses have access to the local mail server and what kind of access they have. Hosts can be listed as , - , or simply - passed to sendmail's error + , or , or can be + passed to Sendmail's error handling routine with a given mailer error. Hosts that - are listed as , which is the default, - are allowed to send mail to this host as long as the mail's - final destination is the local machine. Hosts that are + are listed as , which is the default + option, are allowed to send mail to this host as long as the + mail's final destination is the local machine. Hosts that are listed as are rejected for all mail - connections. Hosts that have the - option for their hostname are allowed to send mail for any - destination through this mail server. + connections. Hosts that are listed as + are allowed to send mail for any + destination using this mail server. - Configuring the <application>sendmail</application> + <title>Configuring the <application>Sendmail</application> Access Database cyberspammer.com 550 We do not accept mail from spammers FREE.STEALTH.MAILER@ 550 We do not accept mail from spammers another.source.of.spam REJECT okay.cyberspammer.com OK 128.32 RELAY - In this example we have five entries. Mail senders that - match the left hand side of the table are affected by the - action on the right side of the table. The first two examples - give an error code to sendmail's - error handling routine. The message is printed to the remote - host when a mail matches the left hand side of the table. - The next entry rejects mail from a specific host on the - Internet, another.source.of.spam. The next - entry accepts mail connections from a host This example shows five entries. Mail senders that match + the left side of the table are affected by the action on the + right side of the table. The first two examples give an error + code to Sendmail's error handling + routine. The message is sent to the remote host when a mail + matches the left side of the table. The third entry rejects + mail from a specific host on the Internet, + another.source.of.spam. The fourth entry + accepts mail connections from okay.cyberspammer.com, which is - more exact than the cyberspammer.com line above. More specific matches override less exact matches. The last - entry allows relaying of electronic mail from hosts with an - IP address that begins with 128.32. These - hosts would be able to send mail through this mail server - that are destined for other mail servers. + entry allows relaying of email from hosts with an IP address + that begins with 128.32. These hosts can + send mail through this mail server that is destined for other + mail servers. - When this file is updated, you need to run - make in /etc/mail/ - to update the database. + Whenever this file is updated, run + make in /etc/mail/ to update the + database. <filename>/etc/mail/aliases</filename> - The aliases database contains a list of virtual mailboxes - that are expanded to other user(s), files, programs or other - aliases. Here are a few examples that can be used in - /etc/mail/aliases: + This database contains a list of virtual mailboxes that + are expanded to other user(s), files, programs, or other + aliases. Here are a few examples to illustrate the + file format: Mail Aliases root: localuser ftp-bugs: joe,eric,paul bit.bucket: /dev/null procmail: "|/usr/local/bin/procmail" - The file format is simple; the mailbox name on the left - side of the colon is expanded to the target(s) on the right. - The first example expands the mailbox - root to the mailbox + The mailbox name on the left side of the colon is expanded + to the target(s) on the right. The first entry expands the + mailbox root to the mailbox localuser, which is then looked up again - in the aliases database. If no match is found, then the - message is delivered to the local user - localuser. The next example shows a + in the aliases database. If no match is + found, the message is delivered to + localuser. The second entry shows a mail list. Mail to the mailbox ftp-bugs is expanded to the three local mailboxes joe, eric, and - paul. Note that a remote mailbox could - be specified as user@example.com. The next - example shows writing mail to a file, in this case - /dev/null. The last example shows - sending mail to a program, in this case the mail message is - written to the standard input of - /usr/local/bin/procmail through a &unix; + paul. A remote mailbox could be + specified as user@example.com. The third + entry shows how to write mail to a file, in this case + /dev/null. The last entry demonstrates + how to send mail to a program, + /usr/local/bin/procmail, through a &unix; pipe. - When this file is updated, you need to run - make in /etc/mail/ - to update the database. + Whenever this file is updated, run + make in /etc/mail/ to update the + database. <filename>/etc/mail/local-host-names</filename> This is a list of hostnames &man.sendmail.8; is to accept as the local host name. Place any domains or hosts that - sendmail is to be receiving mail - for. For example, if this mail server was to accept mail for - the domain example.com and - the host mail.example.com, its - local-host-names might look something - like this: + Sendmail will receive mail + for. For example, to configure a mail server to accept mail + for the domain example.com + and the host mail.example.com, + add these entries to + local-host-names: example.com mail.example.com - When this file is updated, &man.sendmail.8; needs to be - restarted to read the changes. + Whenever this file is updated, &man.sendmail.8; needs to be + restarted so that it will read the changes. <filename>/etc/mail/sendmail.cf</filename> - sendmail's master configuration - file, sendmail.cf controls the overall - behavior of sendmail, including - everything from rewriting e-mail addresses to printing rejection - messages to remote mail servers. Naturally, with such a diverse - role, this configuration file is quite complex and its details - are a bit out of the scope of this section. Fortunately, this - file rarely needs to be changed for standard mail - servers. - - The master sendmail configuration + This is the master configuration file for + Sendmail. It controls the overall + behavior of Sendmail, including + everything from rewriting email addresses to printing rejection + messages to remote mail servers. Accordingly, this + configuration file is quite complex. Fortunately, this file + rarely needs to be changed for standard mail servers. + + The master Sendmail configuration file can be built from &man.m4.1; macros that define the - features and behavior of sendmail. - Please see + features and behavior of Sendmail. + Refer to /usr/src/contrib/sendmail/cf/README for some of the details. - When changes to this file are made, - sendmail needs to be restarted for + Whenever changes to this file are made, + Sendmail needs to be restarted for the changes to take effect. <filename>/etc/mail/virtusertable</filename> The virtusertable maps mail addresses for virtual domains and mailboxes to real mailboxes. These mailboxes can be local, remote, aliases defined in - /etc/mail/aliases or files. + /etc/mail/aliases, or files. Example Virtual Domain Mail Map root@example.com root postmaster@example.com postmaster@noc.example.net @example.com joe - In the above example, we have a mapping for a domain + The above example contains a mapping for the domain example.com. This file - is processed in a first match order down the file. The first - item maps root@example.com to the local mailbox - root. The next entry maps + is processed in a first match order. The first item maps + root@example.com to the local mailbox + root. The second entry maps postmaster@example.com to the mailbox - postmaster on the host - noc.example.net. Finally, if + postmaster on the host noc.example.net. Finally, if nothing from example.com has matched so far, it will match the last mapping, which matches every other mail message addressed to someone at - example.com. This will - be mapped to the local mailbox - joe. + example.com to the local + mailbox joe. Andrew Boothman Written by Gregory Neil Shapiro - Information taken from e-mails written + Information taken from emails written by - Changing Your Mail Transfer Agent + Changing the Mail Transfer Agent email change mta - As already mentioned, FreeBSD comes with - sendmail already installed as your - MTA (Mail Transfer Agent). Therefore by default it is - in charge of your outgoing and incoming mail. + &os; comes with Sendmail already + installed as the MTA which is in charge of + outgoing and incoming mail. - However, for a variety of reasons, some system - administrators want to change their system's MTA. These - reasons range from merely wanting to try out another MTA to - needing a specific feature or package which relies on another - mailer. Fortunately, whatever the reason, FreeBSD makes it + However, the system administrator can change the system's + MTA. The reasons for doing so range from + wanting to try out another MTA to needing a + specific feature or package which relies on another + MTA. Whatever the reason, &os; makes it easy to make the change. - Install a New MTA - - You have a wide choice of MTAs available. A good - starting point is the - FreeBSD Ports Collection where - you will be able to find many. Of course you are free to use - any MTA you want from any location, as long as you can make - it run under FreeBSD. - - Start by installing your new MTA. Once it is installed - it gives you a chance to decide if it really fulfills your - needs, and also gives you the opportunity to configure your - new software before getting it to take over from - sendmail. When doing this, you - should be sure that installing the new software will not - attempt to overwrite system binaries such as - /usr/bin/sendmail. Otherwise, your new - mail software has essentially been put into service before - you have configured it. - - Please refer to your chosen MTA's documentation for - information on how to configure the software you have - chosen. + Install a New <acronym>MTA</acronym> + + A wide choice of MTAs is available + from the mail category of the &os; Ports Collection. + + Once a new MTA is installed, configure + the new software and decide if it really fulfills your needs + before replacing Sendmail. + + Refer to the new chosen MTA's + documentation for information on how to configure the + software. - Disable <application>sendmail</application> + Disable <application>Sendmail</application> - If you disable sendmail's - outgoing mail service, it is important that you replace it - with an alternative mail delivery system. If - you choose not to, system functions such as - &man.periodic.8; will be unable to deliver their results - by e-mail as they would normally expect to. Many parts of - your system may expect to have a functional - sendmail-compatible system. If - applications continue to use - sendmail's binaries to try to - send e-mail after you have disabled them, mail could go - into an inactive sendmail queue, - and never be delivered. + If Sendmail's outgoing mail + service is disabled, it is important that it is replaced + with an alternative mail delivery system. Otherwise, system + functions such as &man.periodic.8; will be unable to deliver + their results by email. Many parts of the system expect a + functional MTA. If applications continue + to use Sendmail's binaries to try + to send email they are disabled, mail could go into an + inactive Sendmail queue, and + never be delivered. In order to completely disable - sendmail, including the outgoing - mail service, you must use + Sendmail, including the outgoing + mail service, add or edit the following lines in + /etc/rc.conf: sendmail_enable="NO" sendmail_submit_enable="NO" sendmail_outbound_enable="NO" sendmail_msp_queue_enable="NO" - in /etc/rc.conf. - - If you only want to disable - sendmail's incoming mail service, - you should set + To only disable Sendmail's + incoming mail service, set sendmail_enable="NO" in /etc/rc.conf. More information - on sendmail's startup options - is available from the &man.rc.sendmail.8; manual - page. + on Sendmail's startup options + is available in &man.rc.sendmail.8;. - Running Your New MTA on Boot + Running the New <acronym>MTA</acronym> on Boot - The new MTA can be started during boot by adding a - configuration line to /etc/rc.conf - like the following example for postfix: + The new MTA can be started during + boot by adding a configuration line to + /etc/rc.conf. This example enables the + Postfix MTA: &prompt.root; echo 'postfix_enable=YES' >> /etc/rc.conf - The MTA will now be automatically started during - boot. + The specified MTA will now be + automatically started during boot. - Replacing <application>sendmail</application> as + <title>Replacing <application>Sendmail</application> as the System's Default Mailer - The program sendmail is so - ubiquitous as standard software on &unix; systems that some - software just assumes it is already installed and configured. - For this reason, many alternative MTA's provide their own + Sendmail is so ubiquitous as + standard software on &unix; systems that some software assumes + it is already installed and configured. For this reason, many + alternative MTAs provide their own compatible implementations of the - sendmail command-line interface; - this facilitates using them as drop-in - replacements for sendmail. - - Therefore, if you are using an alternative mailer, - you will need to make sure that software trying to execute - standard sendmail binaries such as - /usr/bin/sendmail actually executes - your chosen mailer instead. Fortunately, FreeBSD provides - a system called &man.mailwrapper.8; that does this job for - you. - - When sendmail is operating - as installed, you will find something like the following - in /etc/mail/mailer.conf: + Sendmail command-line interface in + order to facilitate using them as drop-in + replacements for Sendmail. + + When using an alternative MTA, + make sure that software trying to execute standard + Sendmail binaries, such as + /usr/bin/sendmail, actually execute + the chosen mailer instead. Fortunately, &os; provides a + system called &man.mailwrapper.8; for this purpose. + + When Sendmail is operating + as installed, + /etc/mail/mailer.conf will look like + this: sendmail /usr/libexec/sendmail/sendmail send-mail /usr/libexec/sendmail/sendmail mailq /usr/libexec/sendmail/sendmail newaliases /usr/libexec/sendmail/sendmail hoststat /usr/libexec/sendmail/sendmail purgestat /usr/libexec/sendmail/sendmail - This means that when any of these common commands - (such as sendmail itself) are run, - the system actually invokes a copy of mailwrapper named - sendmail, which checks - mailer.conf and executes - /usr/libexec/sendmail/sendmail - instead. This system makes it easy to change what binaries - are actually executed when these default - sendmail functions are invoked. - - Therefore if you wanted + When any of the commands listed on the left are run, + the system actually executes the associated command shown on + the right instead. This system makes it easy to change what + binaries are executed when these default + Sendmail functions are invoked. + + As an example, to run /usr/local/supermailer/bin/sendmail-compat - to be run instead of sendmail, you - could change /etc/mail/mailer.conf to - read: + instead of Sendmail, specify the + paths to the installed applications in + /etc/mail/mailer.conf: sendmail /usr/local/supermailer/bin/sendmail-compat send-mail /usr/local/supermailer/bin/sendmail-compat mailq /usr/local/supermailer/bin/mailq-compat newaliases /usr/local/supermailer/bin/newaliases-compat hoststat /usr/local/supermailer/bin/hoststat-compat purgestat /usr/local/supermailer/bin/purgestat-compat Finishing - Once you have everything configured the way you want - it, you should either kill the - sendmail processes that you - no longer need and start the processes belonging to your - new software, or simply reboot. Rebooting will also - give you the opportunity to ensure that you have correctly - configured your system to start your new MTA automatically - on boot. + Once everything is configured, either kill the + unneeded sendmail processes and + start the processes belonging to the new software, or + reboot. Rebooting provides the opportunity to ensure that + the system is correctly configured to start the new + MTA automatically on boot. Troubleshooting email troubleshooting Why do I have to use the FQDN for hosts on my site? - You will probably find that the host is actually - in a different domain; for example, if you are in - foo.bar.edu and you wish - to reach a host called mumble in the - bar.edu domain, - you will have to refer to it by the fully-qualified - domain name, The host may actually be in a different domain. + For example, in order for a host in foo.bar.edu to reach a host + called mumble in the bar.edu domain, refer to + it by the Fully-Qualified Domain Name + FQDN, mumble.bar.edu, instead of just mumble. BIND - Traditionally, this was allowed by BSD BIND - resolvers. However the current version of - BIND that ships with - FreeBSD no longer provides default abbreviations - for non-fully qualified domain names other than the - domain you are in. So an unqualified host + This is because the version of + BIND which ships with + &os; no longer provides default abbreviations + for non-FQDNs other than the local domain. An + unqualified host such as mumble must either be found as mumble.foo.bar.edu, - or it will be searched for in the root - domain. + or it will be searched for in the root domain. - This is different from the previous behavior, - where the search continued across In older versions of + BIND, + the search continued across mumble.bar.edu, and - mumble.edu. Have - a look at RFC 1535 for why this was considered bad - practice, or even a security hole. + mumble.edu. RFC + 1535 details why this is considered bad practice or + even a security hole. - As a good workaround, you can place the - line: + As a good workaround, place the line: search foo.bar.edu bar.edu instead of the previous: domain foo.bar.edu - into your /etc/resolv.conf. + into /etc/resolv.conf. However, make sure that the search order does not go beyond the boundary between local and public administration, as RFC 1535 calls it. - sendmail says - mail loops back to myself + Sendmail says + mail loops back to myself. - This is answered in the - sendmail FAQ as follows: + This is answered in the Sendmail + FAQ as follows. This FAQ is recommended reading + when tweaking the mail setup. I'm getting these error messages: 553 MX list for domain.net points back to relay.domain.net 554 <user@domain.net>... Local configuration error How can I solve this problem? You have asked mail to the domain (e.g., domain.net) to be forwarded to a specific host (in this case, relay.domain.net) by using an MX record, but the relay machine does not recognize itself as domain.net. Add domain.net to /etc/mail/local-host-names [known as /etc/sendmail.cw prior to version 8.10] (if you are using FEATURE(use_cw_file)) or add Cw domain.net to /etc/mail/sendmail.cf. - The sendmail FAQ can be - found at - and is recommended reading if you want to do any - tweaking of your mail setup. How can I run a mail server on a dial-up PPP host? - You want to connect a FreeBSD box on a LAN to the - Internet. The FreeBSD box will be a mail gateway for the - LAN. The PPP connection is non-dedicated. + Connect to a &os; mail gateway on the LAN. The PPP + connection is non-dedicated. - UUCP MX record - There are at least two ways to do this. One way is - to use UUCP. - - Another way is to get a full-time Internet server to - provide secondary MX services for your domain. For example, - if your company's domain is example.com and your Internet - service provider has set example.net up to provide - secondary MX services to your domain: + One way to do this is to get a full-time Internet server + to provide secondary MX services for the + domain. In this example, the domain is example.com and the ISP has + configured example.net to provide + secondary MX services to the + domain: example.com. MX 10 example.com. MX 20 example.net. - Only one host should be specified as the final recipient - (add Cw example.com in + Only one host should be specified as the final + recipient. For Sendmail, add + Cw example.com in /etc/mail/sendmail.cf on - example.com). - - When the sending sendmail is trying - to deliver the mail it will try to connect to you (example.com) over the modem - link. It will most likely time out because you are not - online. The program sendmail - will automatically deliver it to the secondary MX site, - i.e., your Internet provider (example.net). The secondary - MX site will then periodically try to connect to - your host and deliver the mail to the primary MX host - (example.com). - - You might want to use something like this as a login + example.com. + + When the sending MTA attempts + to deliver mail, it will try to connect to the system, + example.com, over the PPP + link. This will time out if the destination is offline. + The MTA will automatically deliver it to + the secondary MX site at the Internet + Service Provider (ISP), example.net. The secondary + MX site will periodically try to connect + to the primary MX host, example.com. + + Use something like this as a login script: #!/bin/sh # Put me in /usr/local/bin/pppmyisp ( sleep 60 ; /usr/sbin/sendmail -q ) & /usr/sbin/ppp -direct pppmyisp - If you are going to create a separate login script for - a user you could use sendmail - -qRexample.com instead in the script above. - This will force all mail in your queue for When creating a separate login script for users, instead + use sendmail -qRexample.com in the script + above. This will force all mail in the queue for example.com to be processed immediately. - A further refinement of the situation is as - follows: - - Message stolen from the &a.isp;. + A further refinement of the situation can be seen from + this example from the &a.isp;: > we provide the secondary MX for a customer. The customer connects to > our services several times a day automatically to get the mails to > his primary MX (We do not call his site when a mail for his domains > arrived). Our sendmail sends the mailqueue every 30 minutes. At the > moment he has to stay 30 minutes online to be sure that all mail is > gone to the primary MX. > > Is there a command that would initiate sendmail to send all the mails > now? The user has not root-privileges on our machine of course. In the privacy flags section of sendmail.cf, there is a definition Opgoaway,restrictqrun Remove restrictqrun to allow non-root users to start the queue processing. You might also like to rearrange the MXs. We are the 1st MX for our customers like this, and we have defined: # If we are the best MX for a host, try directly instead of generating # local config error. OwTrue That way a remote site will deliver straight to you, without trying the customer connection. You then send to your customer. Only works for hosts, so you need to get your customer to name their mail machine customer.com as well as hostname.customer.com in the DNS. Just put an A record in the DNS for customer.com. Why do I keep getting Relaying Denied errors when sending mail from other hosts? - In default FreeBSD installations, - sendmail is configured to only + In a default &os; installation, + Sendmail is configured to only send mail from the host it is running on. For example, - if a POP server is available, then - users will be able to check mail from school, work, or - other remote locations but they still will not be able - to send outgoing emails from outside locations. - Typically, a few moments after the attempt, an email will - be sent from MAILER-DAEMON - with a 5.7 Relaying Denied error - message. - - There are several ways to get around this. The most - straightforward solution is to put your ISP's address in - a relay-domains file at - /etc/mail/relay-domains. A quick way - to do this would be: + if a POP server is available, users + will be able to check mail from remote locations but they + will not be able to send outgoing emails from outside + locations. Typically, a few moments after the attempt, an + email will be sent from MAILER-DAEMON + with a 5.7 Relaying Denied. + + The most straightforward solution is to add the ISP's + FQDN to /etc/mail/relay-domains, as + seen in this example: &prompt.root; echo "your.isp.example.com" > /etc/mail/relay-domains - After creating or editing this file you must restart - sendmail. This works great if - you are a server administrator and do not wish to send - mail locally, or would like to use a point and click - client/system on another machine or even another ISP. It - is also very useful if you only have one or two email - accounts set up. If there are a large number of addresses - to add, open this file in your favorite - text editor and then add the domains, one per line: + After creating or editing this file, restart + Sendmail. This works great if + the server administrator does not wish to send mail + locally, would like to use a MUA on a + remote machine, or would like to use another + ISP for remote connections. It is also + useful when there is only one or two email accounts. If + there are a large number of addresses, add them one per + line: your.isp.example.com other.isp.example.net users-isp.example.org www.example.org - Now any mail sent through your system, by any host in - this list (provided the user has an account on your - system), will succeed. This is a very nice way to allow - users to send mail from your system remotely without - allowing people to send SPAM through your system. + Now any mail sent through the system by any host in + this list, provided the user has an account on the system, + will succeed. This allows users to send mail from the + system remotely without opening the system up to relaying + SPAM from the Internet. Advanced Topics - The following section covers more involved topics such as - mail configuration and setting up mail for your entire - domain. + This section covers more involved topics such as mail + configuration and setting up mail for an entire domain. Basic Configuration email configuration - Out of the box, you should be able to send email to - external hosts as long as you have set up - /etc/resolv.conf or are running your own - name server. If you would like to have mail for your host - delivered to the MTA (e.g., - sendmail) on your own FreeBSD host, - there are two methods: + Out of the box, one can send email to external hosts as + long as /etc/resolv.conf is configured or + the network has access to a configured + DNS server. If order to have mail + delivered to the MTA on the &os; host, + do one of the following: - Run your own name server and have your own domain. - For example, FreeBSD.org + Run a DNS server for the + domain. - Get mail delivered directly to your host. This is - done by delivering mail directly to the current DNS name - for your machine. For example, example.FreeBSD.org. + Get mail delivered directly to to the + FQDN for the machine. SMTP - Regardless of which of the above you choose, in order - to have mail delivered directly to your host, it must have - a permanent static IP address (not a dynamic address, as with - most PPP dial-up configurations). If you are behind a - firewall, it must pass SMTP traffic on to you. If you want - to receive mail directly at your host, you need to be sure - of either of two things: + In order to have mail delivered directly to a host, it + must have a permanent static IP address, not a dynamic IP + address. If the system is behind a firewall, it must be + configured to allow SMTP traffic. To receive mail directly at + a host, one of these two must be configured: MX record - Make sure that the (lowest-numbered) MX record in - your DNS points to your host's IP address. + Make sure that the lowest-numbered + MX record in + DNS points to the host's static IP + address. - Make sure there is no MX entry in your DNS for your - host. + Make sure there is no MX entry in + the DNS for the host. - Either of the above will allow you to receive mail - directly at your host. + Either of the above will allow mail to be received + directly at the host. Try this: &prompt.root; hostname example.FreeBSD.org &prompt.root; host example.FreeBSD.org example.FreeBSD.org has address 204.216.27.XX - If that is what you see, mail directly to - yourlogin@example.FreeBSD.org - should work without problems (assuming - sendmail is running correctly on - example.FreeBSD.org). + In this example, mail sent directly to yourlogin@example.FreeBSD.org + should work without problems, assuming + Sendmail is running correctly on + example.FreeBSD.org. - If instead you see something like this: + For this example: &prompt.root; host example.FreeBSD.org example.FreeBSD.org has address 204.216.27.XX example.FreeBSD.org mail is handled (pri=10) by hub.FreeBSD.org - All mail sent to your host (example.FreeBSD.org) will end up being + All mail sent to example.FreeBSD.org will be collected on hub under the same username instead of being sent directly to your host. - The above information is handled by your DNS server. - The DNS record that carries mail routing information is the - Mail eXchange entry. - If no MX record exists, mail will be delivered directly to - the host by way of its IP address. + The above information is handled by the + DNS server. The DNS + record that carries mail routing information is the + MX entry. If no MX + record exists, mail will be delivered directly to the host by + way of its IP address. - The MX entry for The MX entry for freefall.FreeBSD.org at one time looked like this: freefall MX 30 mail.crl.net freefall MX 40 agora.rdrop.com freefall MX 10 freefall.FreeBSD.org freefall MX 20 who.cdrom.com - As you can see, freefall had many MX - entries. The lowest MX number is the host that receives mail - directly if available; if it is not accessible for some - reason, the others (sometimes called backup - MXes) accept messages temporarily, and pass it - along when a lower-numbered host becomes available, - eventually to the lowest-numbered host. - - Alternate MX sites should have separate Internet - connections from your own in order to be most useful. Your - ISP or another friendly site should have no problem providing - this service for you. + freefall had many MX + entries. The lowest MX number is the host + that receives mail directly, if available. If it is not + accessible for some reason, the next lower-numbered host will + accept messages temporarily, and pass it along when a + lower-numbered host becomes available. + + Alternate MX sites should have separate + Internet connections in order to be most useful. Your + ISP can provide this service. - Mail for Your Domain + Mail for a Domain - In order to set up a mailhost (aka mail - server) you need to have any mail sent to various workstations - directed to it. Basically, you want to claim - any mail for any hostname in your domain (in this case *.FreeBSD.org) and divert it to your - mail server so your users can receive their mail on the master - mail server. + When configuring a MTA for a network, + any mail sent to hosts in its domain should be diverted to the + MTA so that users can receive their mail on + the master mail server. DNS To make life easiest, a user account with the same - username should exist on both machines. - Use &man.adduser.8; to do this. + username should exist on both the + MTA and the system with the + MUA. Use &man.adduser.8; to create the + user accounts. - The mailhost you will be using must be the designated mail + The MTA must be the designated mail exchanger for each workstation on the network. This is done - in your DNS configuration like so: + in theDNS configuration with an + MX record: example.FreeBSD.org A 204.216.27.XX ; Workstation MX 10 hub.FreeBSD.org ; Mailhost This will redirect mail for the workstation to the - mailhost no matter where the A record points. The mail is - sent to the MX host. - - You cannot do this yourself unless you are running a DNS - server. If you are not, or cannot run your own DNS server, - talk to your ISP or whoever provides your DNS. - - If you are doing virtual email hosting, the following - information will come in handy. For this example, we - will assume you have a customer with his own domain, in this - case customer1.org, and - you want all the mail for customer1.org sent to your - mailhost, mail.myhost.com. The - entry in your DNS should look like this: + MTA no matter where the A record points. + The mail is sent to the MX host. + + This must be configured on a DNS + server. If the network does not run its own + DNS server, talk to the + ISP or DNS + provider. + + The following is an example of virtual email hosting. + Consider a customer with the domain customer1.org, where all the mail + for customer1.org should be + sent to mail.myhost.com. The + DNS entry should look like this: customer1.org MX 10 mail.myhost.com - You do not need an A record for - customer1.org if you only - want to handle email for that domain. + An A> record is + not needed for customer1.org in order to only + handle email for that domain. However, running + ping against customer1.org will not work + unless an A record exists for it. - - Be aware that pinging customer1.org will not work - unless an A record exists for it. - - - The last thing that you must do is tell - sendmail on your mailhost what - domains and/or hostnames it should be accepting mail for. - There are a few different ways this can be done. Either of - the following will work: + Tell the MTA which domains and/or + hostnames it should accept mail for. Either of the following + will work for Sendmail: - Add the hosts to your - /etc/mail/local-host-names file if - you are using the FEATURE(use_cw_file). - If you are using a version of - sendmail earlier than 8.10, - the file is /etc/sendmail.cw. + Add the hosts to + /etc/mail/local-host-names when + using the FEATURE(use_cw_file). + For versions of + Sendmail earlier than 8.10, + edit /etc/sendmail.cw instead. - Add a Cwyour.host.com line to your - /etc/sendmail.cf or - /etc/mail/sendmail.cf if you are - using sendmail 8.10 or - higher. + Add a Cwyour.host.com line to + /etc/sendmail.cf. For + Sendmail 8.10 or higher, add + that line to + /etc/mail/sendmail.cf. Bill Moran Contributed by Setting Up to Send Only - There are many instances where you may only want to send + There are many instances where one may only want to send mail through a relay. Some examples are: - Your computer is a desktop machine, but you want - to use programs such as &man.send-pr.1;. To do so, you - should use your ISP's mail relay. + The computer is a desktop machine that needs to use + programs such as &man.send-pr.1;, using the + ISP's mail relay. The computer is a server that does not handle mail locally, but needs to pass off all mail to a relay for processing. - Just about any MTA is capable of filling - this particular niche. Unfortunately, it can be very difficult - to properly configure a full-featured MTA - just to handle offloading mail. Programs such as - sendmail and - postfix are largely overkill for - this use. + While any MTA is capable of filling + this particular niche, it can be difficult to properly configure + a full-featured MTA just to handle offloading + mail. Programs such as Sendmail and + Postfix are overkill for this + use. - Additionally, if you are using a typical Internet access - service, your agreement may forbid you from running a - mail server. + Additionally, a typical Internet access service agreement + may forbid one from running a mail server. The easiest way to fulfill those needs is to install the - mail/ssmtp port. Execute - the following commands as root: + mail/ssmtp port: &prompt.root; cd /usr/ports/mail/ssmtp &prompt.root; make install replace clean - Once installed, - mail/ssmtp can be configured - with a four-line file located at + Once installed, mail/ssmtp can be configured with /usr/local/etc/ssmtp/ssmtp.conf: root=yourrealemail@example.com mailhub=mail.example.com rewriteDomain=example.com hostname=_HOSTNAME_ - Make sure you use your real email address for - root. Enter your ISP's outgoing mail relay - in place of mail.example.com - (some ISPs call this the outgoing mail server - or SMTP server). + Use the real email address for root. + Enter the ISP's outgoing mail relay in place + of mail.example.com. Some + ISPs call this the outgoing mail + server or SMTP server). - Make sure you disable sendmail, - including the outgoing mail service. See - for details. + Make sure to disable + Sendmail, including the outgoing mail + service. See for + details. mail/ssmtp has some - other options available. See the example configuration file - in /usr/local/etc/ssmtp or the manual page - of ssmtp for some examples and more - information. + other options available. Refer to the examples in + /usr/local/etc/ssmtp or the manual page + of ssmtp for more information. Setting up ssmtp in this manner - will allow any software on your computer that needs to send - mail to function properly, while not violating your ISP's usage - policy or allowing your computer to be hijacked for - spamming. + allows any software on the computer that needs to send mail to + function properly, while not violating the + ISP's usage policy or allowing the computer + to be hijacked for spamming. Using Mail with a Dialup Connection - If you have a static IP address, you should not need to - adjust anything from the defaults. Set your host name to your - assigned Internet name and sendmail + When using a static IP address, one should not need to + adjust the default configuration. Set the hostname to the + assigned Internet name and Sendmail will do the rest. - If you have a dynamically assigned IP number and use a - dialup PPP connection to the Internet, you will probably have - a mailbox on your ISPs mail server. Let's assume your ISP's - domain is example.net, and - that your user name is user, you have - called your machine bsd.home, and - your ISP has told you that you may use When using a dynamically assigned IP address and a dialup + PPP connection to the Internet, one usually has a mailbox on the + ISP's mail server. In this example, the + ISP's domain is example.net, the user name is + user, the hostname is bsd.home, and the ISP + has allowed relay.example.net as a mail relay. - In order to retrieve mail from your mailbox, you must - install a retrieval agent. The - fetchmail utility is a good choice as - it supports many different protocols. This program is available - as a package or from the Ports Collection (mail/fetchmail). Usually, your + In order to retrieve mail from the ISP's + mailbox, install a retrieval agent from the Ports Collection. + mail/fetchmail is a good + choice as it supports many different protocols. Usually, the ISP will provide POP. - If you are using user PPP, you can - automatically fetch your mail when an Internet connection is - established with the following entry in + When using user PPP, email can be + automatically fetched when an Internet connection is established + with the following entry in /etc/ppp/ppp.linkup: MYADDR: !bg su user -c fetchmail - If you are using sendmail (as - shown below) to deliver mail to non-local accounts, you probably - want to have sendmail process your - mailqueue as soon as your Internet connection is established. - To do this, put this command after the - fetchmail command in + When using Sendmail to deliver + mail to non-local accounts, configure + Sendmail to process the mail queue as + soon as the Internet connection is established. To do this, add + this line after the above fetchmail entry in /etc/ppp/ppp.linkup: !bg su user -c "sendmail -q" - Assume that you have an account for + In this example, there is an account for user on bsd.home. In the home directory of + role="fqdn">bsd.home. In the home directory of user on bsd.home, create a - .fetchmailrc file: + role="fqdn">bsd.home, create a + .fetchmailrc which contains this + line: poll example.net protocol pop3 fetchall pass MySecret This file should not be readable by anyone except user as it contains the password MySecret. In order to send mail with the correct - from: header, you must tell - sendmail to use - user@example.net rather than - user@bsd.home. You may also wish - to tell sendmail to send all mail + from: header, configure + Sendmail to use + user@example.net rather than user@bsd.home and to send all mail via relay.example.net, allowing quicker mail transmission. The following .mc file should suffice: VERSIONID(`bsd.home.mc version 1.0') OSTYPE(bsd4.4)dnl FEATURE(nouucp)dnl MAILER(local)dnl MAILER(smtp)dnl Cwlocalhost Cwbsd.home MASQUERADE_AS(`example.net')dnl FEATURE(allmasquerade)dnl FEATURE(masquerade_envelope)dnl FEATURE(nocanonify)dnl FEATURE(nodns)dnl define(`SMART_HOST', `relay.example.net') Dmbsd.home define(`confDOMAIN_NAME',`bsd.home')dnl define(`confDELIVERY_MODE',`deferred')dnl - Refer to the previous section for details of how to turn - this .mc file into a - sendmail.cf file. Also, do not forget to - restart sendmail after updating + Refer to the previous section for details of how to convert + this file into the + sendmail.cf format. Do not forget to + restart Sendmail after updating sendmail.cf. James Gorham Written by SMTP Authentication - Having SMTP Authentication in place on - your mail server has a number of benefits. - SMTP Authentication can add another layer - of security to sendmail, and has - the benefit of giving mobile users who switch hosts the ability - to use the same mail server without the need to reconfigure - their mail client settings each time. + Configuring SMTP authentication on the + MTA provides a number of benefits. + SMTP authentication adds a layer + of security to Sendmail, and provides + mobile users who switch hosts the ability to use the same + MTA without the need to reconfigure their + mail client's settings each time. Install security/cyrus-sasl2 - from the ports. You can find this port in - security/cyrus-sasl2. - The security/cyrus-sasl2 - port supports a number of compile-time options. For the - SMTP Authentication method we will be using here, make sure - that the option is not - disabled. + from the Ports Collection. This port supports a number of + compile-time options. For the SMTP authentication method + demonstrated in this example, make sure that + is not disabled. After installing security/cyrus-sasl2, - edit /usr/local/lib/sasl2/Sendmail.conf - (or create it if it does not exist) and add the following + edit + /usr/local/lib/sasl2/Sendmail.conf, + or create it if it does not exist, and add the following line: pwcheck_method: saslauthd Next, install security/cyrus-sasl2-saslauthd, - edit /etc/rc.conf to add the following - line: + role="package">security/cyrus-sasl2-saslauthd + and add the following line to + /etc/rc.conf: saslauthd_enable="YES" - and finally start the saslauthd daemon: + Finally, start the saslauthd daemon: &prompt.root; service saslauthd start This daemon serves as a broker for sendmail to authenticate against - your FreeBSD passwd database. This + the &os; &man.passwd.5; database. This saves the trouble of creating a new set of usernames and passwords for each user that needs to use SMTP authentication, and keeps the login and mail password the same. - Now edit /etc/make.conf and add + Next, edit /etc/make.conf and add the following lines: SENDMAIL_CFLAGS=-I/usr/local/include/sasl -DSASL SENDMAIL_LDFLAGS=-L/usr/local/lib SENDMAIL_LDADD=-lsasl2 - These lines will give - sendmail the proper configuration + These lines provide + Sendmail the proper configuration options for linking to cyrus-sasl2 at compile time. Make sure that cyrus-sasl2 has been installed before recompiling - sendmail. + Sendmail. - Recompile sendmail by + Recompile Sendmail by executing the following commands: &prompt.root; cd /usr/src/lib/libsmutil &prompt.root; make cleandir && make obj && make &prompt.root; cd /usr/src/lib/libsm &prompt.root; make cleandir && make obj && make &prompt.root; cd /usr/src/usr.sbin/sendmail &prompt.root; make cleandir && make obj && make && make install - The compile of sendmail - should not have any problems if - /usr/src has not been changed - extensively and the shared libraries it needs are + This compile should not have any problems if + /usr/src has not + changed extensively and the shared libraries it needs are available. - After sendmail has been - compiled and reinstalled, edit your - /etc/mail/freebsd.mc file (or whichever - file you use as your .mc file. Many - administrators choose to use the output from - &man.hostname.1; as the .mc file for - uniqueness). Add these lines to it: + After Sendmail has been + compiled and reinstalled, edit + /etc/mail/freebsd.mc or the local + .mc file. Many administrators choose + to use the output from &man.hostname.1; as the name of the + .mc file for uniqueness. Add these + lines: dnl set SASL options TRUST_AUTH_MECH(`GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN')dnl define(`confAUTH_MECHANISMS', `GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN')dnl These options configure the different methods available - to sendmail for authenticating - users. If you would like to use a method other than - pwcheck, please see the - included documentation. + to Sendmail for authenticating + users. To use a method other than + pwcheck, refer to the + Sendmail documentation. - Finally, run &man.make.1; while in - /etc/mail. That will run your new - .mc file and create a - .cf file named - freebsd.cf (or whatever name you have - used for your .mc file). Then use - the command make install restart, which - will copy the file to sendmail.cf, - and will properly restart - sendmail. For more information - about this process, you should refer to + Finally, run &man.make.1; while in /etc/mail. That will run the + new .mc and create a + .cf named either + freebsd.cf or the name used for the + local .mc. Then, run make + install restart, which will copy the file to + sendmail.cf, and properly restart + Sendmail. For more information + about this process, refer to /etc/mail/Makefile. - If all has gone correctly, you should be able to enter your - login information into the mail client and send a test message. - For further investigation, set the - of sendmail to 13 and watch + To test the configuration, use a MUA to + send a test message. For further investigation, set the + of Sendmail + to 13 and watch /var/log/maillog for any errors. - For more information, please see the - sendmail page regarding - + For more information, refer to SMTP authentication. Marc Silver Contributed by Mail User Agents Mail User Agents - A Mail User Agent (MUA) is an application - that is used to send and receive email. Furthermore, as email - evolves and becomes more complex, - MUA's are becoming increasingly powerful - in the way they interact with email; this gives users increased - functionality and flexibility. &os; contains support for - numerous mail user agents, all of which can be easily installed - using the FreeBSD Ports Collection. - Users may choose between graphical email clients such as - evolution or - balsa, console based clients such - as mutt, - alpine or mail, - or the web interfaces used by some large organizations. + A MUA is an application that is used to + send and receive email. As email evolves and + becomes more complex, MUAs are becoming + increasingly powerful and provide users increased functionality + and flexibility. The mail category of the + &os; Ports Collection contains numerous MUAs. + These include graphical email clients such as + Evolution or + Balsa and console based clients such + as mutt or + alpine. - mail + <command>mail</command> - &man.mail.1; is the default Mail User Agent - (MUA) in &os;. It is a - console based MUA that offers all the basic - functionality required to send and receive text-based email, - though it is limited in interaction abilities with attachments - and can only support local mailboxes. + &man.mail.1; is the default + MUA installed with &os;. It is a console + based MUA that offers the basic + functionality required to send and receive text-based email. + It provides limited attachment support and can only access + local mailboxes. Although mail does not natively support interaction with POP or IMAP servers, these mailboxes may be - downloaded to a local mbox file using an - application such as fetchmail, - which will be discussed later in this chapter (). + downloaded to a local mbox using an + application such as + fetchmail. In order to send and receive email, run mail: &prompt.user; mail - The contents of the user mailbox in - /var/mail are - automatically read by the mail utility. - Should the mailbox be empty, the utility exits with a - message indicating that no mails could be found. Once the - mailbox has been read, the application interface is started, + The contents of the user's mailbox in /var/mail are automatically + read by mail. Should the mailbox be empty, + the utility exits with a message indicating that no mail could + be found. If mail exists, the application interface starts, and a list of messages will be displayed. Messages are automatically numbered, as can be seen in the following example: Mail version 8.1 6/6/93. Type ? for help. "/var/mail/marcs": 3 messages 3 new >N 1 root@localhost Mon Mar 8 14:05 14/510 "test" N 2 root@localhost Mon Mar 8 14:05 14/509 "user account" N 3 root@localhost Mon Mar 8 14:05 14/509 "sample" - Messages can now be read by using the t - mail command, suffixed by the message - number that should be displayed. In this example, we will - read the first email: + Messages can now be read by typing t + followed by the message number. This example reads the first + email: & t 1 Message 1: From root@localhost Mon Mar 8 14:05:52 2004 X-Original-To: marcs@localhost Delivered-To: marcs@localhost To: marcs@localhost Subject: test Date: Mon, 8 Mar 2004 14:05:52 +0200 (SAST) From: root@localhost (Charlie Root) This is a test message, please reply if you receive it. - As can be seen in the example above, the - t key will cause the message to be displayed + As seen in this example, the message will be displayed with full headers. To display the list of messages again, - the h key should be used. + press h. - If the email requires a response, you may use - mail to reply, by using either the + If the email requires a reply, press either R or r - mail keys. The R key - instructs mail to reply only to the sender - of the email, while r replies not only to - the sender, but also to other recipients of the message. - You may also suffix these commands with the mail number which - you would like make a reply to. Once this has been done, the - response should be entered, and the end of the message should - be marked by a single . on a new line. An - example can be seen below: + mail keys. R instructs + mail to reply only to the sender of the + email, while r replies to all other + recipients of the message. These commands can be suffixed + with the mail number of the message to reply to. After typing + the response, the end of the message should be marked by a + single . on its own line. An example can be + seen below: & R 1 To: root@localhost Subject: Re: test Thank you, I did get your email. . EOT - In order to send new email, the m - key should be used, followed by the recipient email address. - Multiple recipients may also be specified by separating each - address with the , delimiter. The subject - of the message may then be entered, followed by the message - contents. The end of the message should be specified by - putting a single . on a new line. + In order to send a new email, press m, + followed by the recipient email address. Multiple recipients + may be specified by separating each address with the + , delimiter. The subject of the message may + then be entered, followed by the message contents. The end of + the message should be specified by putting a single + . on its own line. & mail root@localhost Subject: I mastered mail Now I can send and receive email using mail ... :) . EOT - While inside the mail utility, the - ? command may be used to display help at any - time, the &man.mail.1; manual page should also be consulted - for more help with mail. + While using mail, press + ? to display help at any time. Refer to + &man.mail.1; for more help on how to use + mail. - As previously mentioned, the &man.mail.1; command was - not originally designed to handle attachments, and thus - deals with them very poorly. Newer MUAs - such as mutt handle attachments - in a much more intelligent way. But should you still wish - to use the mail command, the converters/mpack port may be of + &man.mail.1; was not designed to handle attachments and + thus deals with them poorly. Newer MUAs + handle attachments in a more intelligent way. Users who + prefer to use mail may find the converters/mpack port to be of considerable use. - mutt + <application>mutt</application> - mutt is a small yet very - powerful Mail User Agent, with excellent features, just some - of which include: + mutt is a powerful + MUA, with many features, including: - The ability to thread messages; + The ability to thread messages. PGP support for digital signing and encryption of - email; + email. - MIME Support; + MIME support. - Maildir Support; + Maildir support. Highly customizable. - All of these features help to make - mutt one of the most advanced mail - user agents available. See for more + Refer to for more information on mutt. mutt may be installed using the mail/mutt port. After the port has been installed, mutt can be started by issuing the following command: &prompt.user; mutt mutt will automatically read - the contents of the user mailbox in /var/mail and display the - contents if applicable. If no mails are found in the user - mailbox, then mutt will wait for - commands from the user. The example below shows + and display the contents of the user mailbox in /var/mail. If no mails are + found, mutt will wait for commands + from the user. The example below shows mutt displaying a list of messages: - In order to read an email, select it using the cursor - keys and press the Enter key. An example of + To read an email, select it using the cursor keys and + press Enter. An example of mutt displaying email can be seen below: - As with the &man.mail.1; command, - mutt allows users to reply only to - the sender of the message as well as to all recipients. To - reply only to the sender of the email, use the - r keyboard shortcut. To send a group reply, - which will be sent to the original sender as well as all the - message recipients, use the g - shortcut. + Similar to &man.mail.1;, mutt + can be used to reply only to the sender of the message as well + as to all recipients. To reply only to the sender of the + email, press r. To send a group reply + to the original sender as well as all the message recipients, + press g. - mutt makes use of the - &man.vi.1; command as an editor for creating and replying - to emails. This may be customized by the user by creating - or editing their own .muttrc file in - their home directory and setting the - editor variable or by setting the - EDITOR environment variable. See + By default, mutt uses the + &man.vi.1; editor for creating and replying to emails. Each + user can customize this by creating or editing the + .muttrc in their home directory and + setting the editor variable or by setting + the EDITOR environment variable. Refer to for more information about configuring mutt. - In order to compose a new mail message, press + To compose a new mail message, press m. After a valid subject has been given, - mutt will start &man.vi.1; and the - mail can be written. Once the contents of the mail are - complete, save and quit from vi and + mutt will start &man.vi.1; so the + email can be written. Once the contents of the email are + complete, save and quit from vi. mutt will resume, displaying a summary screen of the mail that is to be delivered. In order to send the mail, press y. An example of the summary screen can be seen below: - mutt also contains extensive - help, which can be accessed from most of the menus by pressing - the ? key. The top line also displays the - keyboard shortcuts where appropriate. + mutt contains extensive help + which can be accessed from most of the menus by pressing + ?. The top line also displays the keyboard + shortcuts where appropriate. - alpine + <application>alpine</application> alpine is aimed at a beginner user, but also includes some advanced features. - The alpine software has had - several remote vulnerabilities discovered in the past, which - allowed remote attackers to execute arbitrary code as users - on the local system, by the action of sending a - specially-prepared email. All such - known problems have been fixed, but - the alpine code is written in - a very insecure style and the &os; Security Officer believes - there are likely to be other undiscovered vulnerabilities. - You install alpine at your own + alpine has had several remote + vulnerabilities discovered in the past, which allowed remote + attackers to execute arbitrary code as users on the local + system, by the action of sending a specially-prepared email. + While known problems have been fixed, + alpine code is written in an + insecure style and the &os; Security Officer believes there + are likely to be other undiscovered vulnerabilities. Users + install alpine at their own risk. The current version of alpine may be installed using the mail/alpine port. Once the port has installed, alpine can be started by issuing the following command: &prompt.user; alpine - The first time that alpine - is run it displays a greeting page with a brief introduction, + The first time alpine + runs, it displays a greeting page with a brief introduction, as well as a request from the alpine development team to send an anonymous email message allowing them to judge how many users are using their client. To send this anonymous message, - press Enter, or alternatively press + press Enter. Alternatively, press E to exit the greeting without sending an - anonymous message. An example of the greeting page can be - seen below: + anonymous message. An example of the greeting page is + shown below: - Users are then presented with the main menu, which can - be easily navigated using the cursor keys. This main menu - provides shortcuts for the composing new mails, browsing of - mail directories, and even the administration of address book - entries. Below the main menu, relevant keyboard shortcuts - to perform functions specific to the task at hand are - shown. + The main menu is then presented, which can be navigated + using the cursor keys. This main menu provides shortcuts for + the composing new mails, browsing mail directories, and + administering address book entries. Below the main menu, + relevant keyboard shortcuts to perform functions specific to + the task at hand are shown. The default directory opened by - alpine is the alpine is inbox. To view the message index, press I, or select the - MESSAGE INDEX option as seen + MESSAGE INDEX option shown below: - The message index shows messages in the current directory, + The message index shows messages in the current directory and can be navigated by using the cursor keys. Highlighted - messages can be read by pressing the - Enter key. + messages can be read by pressing + Enter. In the screenshot below, a sample message is displayed by - alpine. Keyboard shortcuts are - displayed as a reference at the bottom of the screen. An - example of one of these shortcuts is the r - key, which tells the MUA to reply to the - current message being displayed. + alpine. Contextual keyboard + shortcuts are displayed at the bottom of the screen. An + example of one of a shortcut is r, which + tells the MUA to reply to the current + message being displayed. Replying to an email in alpine is done using the pico editor, which is installed by default with - alpine. The - pico utility makes it easy to - navigate around the message and is slightly more forgiving - on novice users than &man.vi.1; or &man.mail.1;. Once the - reply is complete, the message can be sent by pressing - alpine. + pico makes it easy to navigate the + message and is easier for novice users to use than &man.vi.1; + or &man.mail.1;. Once the reply is complete, the message can + be sent by pressing CtrlX - . The alpine application - will ask for confirmation. + . alpine + will ask for confirmation before sending the message. - The alpine application can - be customized using the SETUP - option from the main menu. Consult alpine can be customized using + the SETUP option from the main + menu. Consult for more information. Marc Silver Contributed by - Using fetchmail + Using <application>fetchmail</application> fetchmail fetchmail is a full-featured - IMAP and POP client which + IMAP and POP client. It allows users to automatically download mail from remote IMAP and POP servers and - save it into local mailboxes; there it can be accessed more + save it into local mailboxes where it can be accessed more easily. fetchmail can be installed using the mail/fetchmail - port, and offers various features, some of which include: + port, and offers various features, including: - Support of POP3, + Support for the POP3, APOP, KPOP, IMAP, ETRN and ODMR protocols. Ability to forward mail using SMTP, which allows filtering, forwarding, and aliasing to function normally. May be run in daemon mode to check periodically for new messages. - Can retrieve multiple mailboxes and forward them based + Can retrieve multiple mailboxes and forward them, based on configuration, to different local users. - While it is outside the scope of this document to explain - all of fetchmail's features, some - basic features will be explained. The - fetchmail utility requires a - configuration file known as .fetchmailrc, - in order to run correctly. This file includes server - information as well as login credentials. Due to the sensitive - nature of the contents of this file, it is advisable to make - it readable only by the owner, with the following + This section explains some of the basic features of + fetchmail. This utility requires a + .fetchmailrc configuration in the user's + home directory in order to run correctly. This file includes + server information as well as login credentials. Due to the + sensitive nature of the contents of this file, it is advisable + to make it readable only by the user, with the following command: &prompt.user; chmod 600 .fetchmailrc The following .fetchmailrc serves as an example for downloading a single user mailbox using POP. It tells fetchmail to connect to example.com using a username of joesoap and a password of XXX. This example assumes that the user - joesoap is also a user on the local - system. + joesoap exists on the local system. poll example.com protocol pop3 username "joesoap" password "XXX" The next example connects to multiple POP and IMAP servers and redirects to different local usernames where applicable: poll example.com proto pop3: user "joesoap", with password "XXX", is "jsoap" here; user "andrea", with password "XXXX"; poll example2.net proto imap: user "john", with password "XXXXX", is "myth" here; - The fetchmail utility can be - run in daemon mode by running it with the - flag, followed by the interval (in seconds) that - fetchmail should poll servers listed - in the .fetchmailrc file. The following - example would cause fetchmail to poll - every 600 seconds: + fetchmail can be run in daemon + mode by running it with , followed by the + interval (in seconds) that fetchmail + should poll servers listed in .fetchmailrc. + The following example configures + fetchmail to poll every 600 + seconds: &prompt.user; fetchmail -d 600 More information on fetchmail can be found at . Marc Silver Contributed by - Using procmail + Using <application>procmail</application> procmail - The procmail utility is an - incredibly powerful application used to filter incoming mail. - It allows users to define rules which can be - matched to incoming mails to perform specific functions or to - reroute mail to alternative mailboxes and/or email addresses. + procmail is a powerful + application used to filter incoming mail. It allows users to + define rules which can be matched to incoming + mails to perform specific functions or to reroute mail to + alternative mailboxes or email addresses. procmail can be installed using the mail/procmail port. Once installed, it can be directly integrated into most - MTAs; consult your MTA + MTAs. Consult the MTA documentation for more information. Alternatively, procmail can be integrated by adding the following line to a .forward in the - home directory of the user utilizing - procmail features: + home directory of the user: "|exec /usr/local/bin/procmail || exit 75" - The following section will display some basic + The following section displays some basic procmail rules, as well as brief - descriptions on what they do. These rules, and others must be - inserted into a .procmailrc file, which - must reside in the user's home directory. + descriptions of what they do. Rules must be inserted into a + .procmailrc, which must reside in the + user's home directory. - The majority of these rules can also be found in the - &man.procmailex.5; manual page. + The majority of these rules can be found in + &man.procmailex.5;. - Forward all mail from user@example.com to an - external address of To forward all mail from user@example.com to + an external address of goodmail@example2.com: :0 * ^From.*user@example.com ! goodmail@example2.com - Forward all mails shorter than 1000 bytes to an external + To forward all mails shorter than 1000 bytes to an external address of goodmail@example2.com: :0 * < 1000 ! goodmail@example2.com - Send all mail sent to alternate@example.com - into a mailbox called alternate: + To send all mail sent to + alternate@example.com to a mailbox called + alternate: :0 * ^TOalternate@example.com alternate - Send all mail with a subject of Spam to - /dev/null: + To send all mail with a subject of Spam to + /dev/null: :0 ^Subject:.*Spam /dev/null A useful recipe that parses incoming &os;.org mailing lists - and places each list in its own mailbox: + role="domainname">&os;.org mailing lists and places + each list in its own mailbox: :0 * ^Sender:.owner-freebsd-\/[^@]+@FreeBSD.ORG { LISTNAME=${MATCH} :0 * LISTNAME??^\/[^@]+ FreeBSD-${MATCH} } diff --git a/en_US.ISO8859-1/books/handbook/multimedia/chapter.xml b/en_US.ISO8859-1/books/handbook/multimedia/chapter.xml index f14f0ea81c..529bd216e4 100644 --- a/en_US.ISO8859-1/books/handbook/multimedia/chapter.xml +++ b/en_US.ISO8859-1/books/handbook/multimedia/chapter.xml @@ -1,1967 +1,1797 @@ Ross Lippert Edited by Multimedia Synopsis - FreeBSD supports a wide variety of sound cards, allowing you - to enjoy high fidelity output from your computer. This includes + &os; supports a wide variety of sound cards, allowing users + to enjoy high fidelity output from a &os; system. This includes the ability to record and playback audio in the MPEG Audio Layer - 3 (MP3), WAV, and Ogg Vorbis formats as well as many other - formats. The FreeBSD Ports Collection also contains - applications allowing you to edit your recorded audio, add sound - effects, and control attached MIDI devices. - - With some experimentation, &os; can support - playback of video files and DVDs. The number of applications - to encode, convert, and playback various video media is more - limited than the number of sound applications. For example as - of this writing, there are no good re-encoding applications - in the FreeBSD Ports Collection that could be used to convert - between formats, as there is with audio/sox. However, the software - landscape in this area is changing rapidly. - - This chapter will describe the necessary steps to configure - your sound card. The configuration and installation of X11 - () has already taken care of the - hardware issues for your video card, though there may be some - tweaks to apply for better playback. - - After reading this chapter, you will know: + 3 (MP3), Waveform Audio File + (WAV), Ogg Vorbis, and other formats. The + &os; Ports Collection contains many applications for editing + recorded audio, adding sound effects, and controlling attached + MIDI devices. + + &os; also supports the playback of video files and DVDs. + The &os; Ports Collection contains applications to encode, + convert, and playback various video media. + + This chapter describes how to configure sound cards, video + playback, TV tuner cards, and scanners on &os;. It also + describes some of the applications which are available for + using these devices. + + After reading this chapter, you will know how to: - How to configure your system so that your sound card - is recognized. + Configure a sound card on os;. - Methods to test whether your card is working. + Troubleshoot the sound setup. - How to troubleshoot your sound setup. + Playback and encode MP3s and other audio. - How to playback and encode MP3s and other audio. + Prepare a &os; system for video playback. - How video is supported by the X server. + Playback DVDs, .mpg, and + .avi files. - Some video player/encoder ports which give good - results. + Rip CD and DVD content into files. - How to playback DVDs, .mpg and - .avi files. + Configure a TV card. - How to rip CD and DVD content into files. + Install and setup MythTV on &os; - How to configure a TV card. + Configure an image scanner. How to configure an image scanner. Before reading this chapter, you should: Know how to configure and install a new kernel (). - Trying to mount audio CDs with the &man.mount.8; command - will result in an error, at least, and a kernel - panic, at worst. These media have specialized - encodings which differ from the usual ISO-filesystem. + Audio CDs have specialized encodings which differ from the + usual ISO-filesystem. This means that they should not be + mounted using &man.mount.8;. Moses Moore Contributed by Marc Fonvieille Enhanced by Setting Up the Sound Card Configuring the System PCI - ISA sound cards - Before you begin, you should know the model of the card - you have, the chip it uses, and whether it is a PCI or ISA - card. FreeBSD supports a wide variety of both PCI and ISA - cards. Check the supported audio devices list of the Hardware Notes to - see if your card is supported. The Hardware Notes will - also mention which driver supports your card. + Before beginning the configuration, determine the model of + the sound card and the chip it uses. &os; supports a wide + variety of sound cards. Check the supported audio devices + list of the Hardware + Notes to see if the card is supported and which &os; + driver it uses. kernel configuration - To use your sound device, you will need to load the proper - device driver. This may be accomplished in one of two ways. - The easiest way is to simply load a kernel module for your - sound card with &man.kldload.8; which can either be done from - the command line: + In order to use the sound device, the proper device driver + must be loaded. This may be accomplished in one of two ways. + The easiest way is to load a kernel module for the sound card + with &man.kldload.8;. This example loads the driver for a + Creative &soundblaster; Live! sound card: &prompt.root; kldload snd_emu10k1 - or by adding the appropriate line to the file - /boot/loader.conf like this: + To automate the loading of this driver at boot time, add the + driver to /boot/loader.conf. The line for + this driver is: snd_emu10k1_load="YES" - These examples are for a Creative &soundblaster; Live! sound - card. Other available loadable sound modules are listed in - /boot/defaults/loader.conf. - If you are not sure which driver to use, you may try to load - the snd_driver module: + Other available sound modules are listed in + /boot/defaults/loader.conf. When unsure + which driver to use, load the snd_driver + module: &prompt.root; kldload snd_driver - This is a metadriver loading the most common device drivers - at once. This speeds up the search for the correct driver. It - is also possible to load all sound drivers via the - /boot/loader.conf facility. + This is a metadriver which loads all of the most common + sound drivers and can be used to speed up the search for the + correct driver. It is also possible to load all sound drivers + by adding the metadriver to + /boot/loader.conf. - If you wish to find out the driver selected for your - soundcard after loading the snd_driver - metadriver, you may check the /dev/sndstat - file with the cat /dev/sndstat - command. + To determine which driver was selected for the sound card + after loading the snd_driver metadriver, + type cat /dev/sndstat. - A second method is to statically - compile in support for your sound card in your kernel. The - section below provides the information you need to add support - for your hardware in this manner. For more information about - recompiling your kernel, please see . + Users who prefer to statically compile in support for the + sound card in a custom kernel should refer to the instructions + in the next section. For more information about recompiling a + kernel, refer to . Configuring a Custom Kernel with Sound Support - The first thing to do is add the audio framework driver - &man.sound.4; to the kernel; for that you will need to - add the following line to the kernel configuration file: + When using a custom kernel to provide sound support, make + sure that the audio framework driver exists in the custom kernel + configuration file: device sound - Next, you have to add the support for your sound card. - Therefore, you need to know which driver supports the card. - Check the supported audio devices list of the Hardware Notes, to - determine the correct driver for your sound card. For - example, a Creative &soundblaster; Live! sound card is - supported by the &man.snd.emu10k1.4; driver. To add the support - for this card, use the following: + Next, add support for the sound card. Therefore, you need + to know which driver supports the card. To continue the example + of the Creative &soundblaster; Live! sound card from the + previous section, use the following line in the custom kernel + configuration file: device snd_emu10k1 Be sure to read the manual page of the driver for the syntax to use. The explicit syntax for the kernel configuration of every supported sound driver can also be - found in the /usr/src/sys/conf/NOTES - file. - - Non-PnP ISA sound cards may require you to provide the - kernel with information on the card settings (IRQ, I/O port, - etc), as is true of all non-PnP ISA cards. This is done via - the /boot/device.hints file. During the - boot process, the &man.loader.8; will read this file and pass - the settings to the kernel. For example, an old Creative + found in /usr/src/sys/conf/NOTES. + + Non-PnP ISA sound cards may require the IRQ and I/O port + settings of the card to be added to + /boot/device.hints. During the boot + process, &man.loader.8; reads this file and passes the + settings to the kernel. For example, an old Creative &soundblaster; 16 ISA non-PnP card will use the &man.snd.sbc.4; driver in conjunction with - snd_sb16. For this card the following + snd_sb16. For this card, the following lines must be added to the kernel configuration file: device snd_sbc device snd_sb16 - and these to + If the card uses the 0x220 I/O port and + IRQ 5, these lines must also be added to /boot/device.hints: hint.sbc.0.at="isa" hint.sbc.0.port="0x220" hint.sbc.0.irq="5" hint.sbc.0.drq="1" hint.sbc.0.flags="0x15" In this case, the card uses the 0x220 I/O port and the IRQ 5. - The syntax used in the - /boot/device.hints file is covered in the - &man.sound.4; driver manual page and the manual page - for the driver in question. + The syntax used in + /boot/device.hints is described in + &man.sound.4; and the manual page for the driver of the sound + card. The settings shown above are the defaults. In some - cases, you may need to change the IRQ or the other settings to - match your card. See the &man.snd.sbc.4; manual page for more - information about this card. + cases, the IRQ or other settings may need to be changed to + match the card. Refer to &man.snd.sbc.4; for more information + about this card. Testing the Sound Card - After rebooting with the modified kernel, or after loading - the required module, the sound card should appear in your system - message buffer (&man.dmesg.8;) as something like: + After rebooting into the custom kernel, or after loading + the required module, the sound card should appear in the system + message buffer. Run &man.dmesg.8; and look for a message + like: pcm0: <Intel ICH3 (82801CA)> port 0xdc80-0xdcbf,0xd800-0xd8ff irq 5 at device 31.5 on pci0 pcm0: [GIANT-LOCKED] pcm0: <Cirrus Logic CS4205 AC97 Codec> - The status of the sound card may be checked via the - /dev/sndstat file: + The status of the sound card may also be checked using this + command: &prompt.root; cat /dev/sndstat FreeBSD Audio Driver (newpcm) Installed devices: pcm0: <Intel ICH3 (82801CA)> at io 0xd800, 0xdc80 irq 5 bufsz 16384 kld snd_ich (1p/2r/0v channels duplex default) - The output from your system may vary. If no + The output may vary between systems. If no pcm devices are listed, go back and - review what was done earlier. Go through your kernel - configuration file again and make sure the correct + review the kernel configuration file and make sure the correct device driver was chosen. Common problems are listed in . - If all goes well, you should now have a functioning sound - card. If your CD-ROM or DVD-ROM drive's audio-out pins are - properly connected to your sound card, you can put a CD in the + If all goes well, the sound card should now work in os;. If + the CD-ROM or DVD-ROM drive's audio-out pins are properly + connected to the sound card, one can insert an audio CD in the drive and play it with &man.cdcontrol.1;: &prompt.user; cdcontrol -f /dev/acd0 play 1 Various applications, such as audio/workman can provide a - friendlier interface. You may want to install an application - such as audio/mpg123 to - listen to MP3 audio files. + role="package">audio/workman provide a friendlier + interface. The audio/mpg123 + port can be installed to listen to MP3 audio files. - Another quick way to test the card is sending data - to /dev/dsp, like this: + Another quick way to test the card is to send data to + /dev/dsp: &prompt.user; cat filename > /dev/dsp where filename can - be any file. This command line should produce some noise, - confirming the sound card is actually working. + be any file. This command should produce some noise, confirming + that the sound card is actually working. - The device nodes /dev/dsp* will be - created automatically when needed. If they are not used, they + The /dev/dsp* device nodes will + be created automatically as needed. When not in use, they do not exist and will not appear in the output of &man.ls.1;. - Sound card mixer levels can be changed via the &man.mixer.8; - command. More details can be found in the &man.mixer.8; manual - page. + Sound card mixer levels can be changed using &man.mixer.8;. + More details can be found in &man.mixer.8;. Common Problems device nodes I/O port IRQ DSP Error Solution sb_dspwr(XX) timed out The I/O port is not set correctly. bad irq XX The IRQ is set incorrectly. Make sure that the set IRQ and the sound IRQ are the same. xxx: gus pcm not attached, out of memory There is not enough available memory to use the device. xxx: can't open /dev/dsp! Check with fstat | grep - dsp - if another application is holding the device open. - Noteworthy troublemakers are + dsp if another application is holding the + device open. Noteworthy troublemakers are esound and KDE's sound support. Another issue is that modern graphics cards often come with their own sound driver, for use with HDMI and similar. This sound device will - sometimes be enumerated before the actual soundcard and the - soundcard will subsequently not be used as the default - playback device. To check if this is the case, run + sometimes be enumerated before the sound card and the sound + card will subsequently not be used as the default playback + device. To check if this is the case, run dmesg and look for pcm. The output looks something like this: ... hdac0: HDA Driver Revision: 20100226_0142 hdac1: HDA Driver Revision: 20100226_0142 hdac0: HDA Codec #0: NVidia (Unknown) hdac0: HDA Codec #1: NVidia (Unknown) hdac0: HDA Codec #2: NVidia (Unknown) hdac0: HDA Codec #3: NVidia (Unknown) pcm0: <HDA NVidia (Unknown) PCM #0 DisplayPort> at cad 0 nid 1 on hdac0 pcm1: <HDA NVidia (Unknown) PCM #0 DisplayPort> at cad 1 nid 1 on hdac0 pcm2: <HDA NVidia (Unknown) PCM #0 DisplayPort> at cad 2 nid 1 on hdac0 pcm3: <HDA NVidia (Unknown) PCM #0 DisplayPort> at cad 3 nid 1 on hdac0 hdac1: HDA Codec #2: Realtek ALC889 pcm4: <HDA Realtek ALC889 PCM #0 Analog> at cad 2 nid 1 on hdac1 pcm5: <HDA Realtek ALC889 PCM #1 Analog> at cad 2 nid 1 on hdac1 pcm6: <HDA Realtek ALC889 PCM #2 Digital> at cad 2 nid 1 on hdac1 pcm7: <HDA Realtek ALC889 PCM #3 Digital> at cad 2 nid 1 on hdac1 ... Here the graphics card (NVidia) has been enumerated before the sound card (Realtek - ALC889). To use the sound card as default playback - device, change hw.snd.default_unit to the - unit that should be used for playback, enter the - following: + ALC889). To use the sound card as the default + playback device, change hw.snd.default_unit + to the unit that should be used for playback: &prompt.root; sysctl hw.snd.default_unit=n Here, n is the number of the sound - device to use, in this example 4. You can - make this change permanent by adding the following line to + device to use. In this example, it should be + 4. Make this change permanent by adding + the following line to /etc/sysctl.conf: hw.snd.default_unit=4 Munish Chopra Contributed by Utilizing Multiple Sound Sources It is often desirable to have multiple sources of sound that - are able to play simultaneously, such as when - esound or - artsd do not support sharing of the - sound device with a certain application. - - FreeBSD lets you do this through Virtual Sound - Channels, which can be enabled with the - &man.sysctl.8; facility. Virtual channels allow you to - multiplex your sound card's playback by mixing sound in the - kernel. + are able to play simultaneously. &os; uses Virtual + Sound Channels, which can be enabled using + &man.sysctl.8;. Virtual channels allow one to multiplex the + sound card's playback by mixing sound in the kernel. - To set the number of virtual channels, there are three - sysctl knobs which, if you are the root - user, can be set like this: + To set the number of virtual channels, three + &man.sysctl.8; knobs are available: &prompt.root; sysctl dev.pcm.0.play.vchans=4 &prompt.root; sysctl dev.pcm.0.rec.vchans=4 &prompt.root; sysctl hw.snd.maxautovchans=4 The above example allocates four virtual channels, which is a practical number for everyday use. Both dev.pcm.0.play.vchans=4 and dev.pcm.0.rec.vchans=4 are the number of virtual channels pcm0 has for playback - and recording, and are configurable once a device has been + and recording, and are configurable after a device has been attached. hw.snd.maxautovchans is the number of virtual channels a new audio device is given when it is attached using &man.kldload.8;. Since the pcm module can be loaded independently of the hardware drivers, hw.snd.maxautovchans - can store how many virtual channels any devices which are - attached later will be given. Refer to &man.pcm.4; manual page - for more information. + indicates how many virtual channels will be given to devices + when they are attached. Refer to &man.pcm.4; for more + information. - You cannot change the number of virtual channels for a - device while it is in use. First close any programs using + The number of virtual channels for a device cannot be + changed while it is in use. First, close any programs using the device, such as music players or sound daemons. The correct pcm device will - automatically be allocated transparently to a program - that requests /dev/dsp0. + automatically be allocated transparently to a program that + requests /dev/dsp0. Josef El-Rayes Contributed by Setting Default Values for Mixer Channels The default values for the different mixer channels are - hardcoded in the sourcecode of the &man.pcm.4; driver. There - are many different applications and daemons that allow - you to set values for the mixer that are remembered between - invocations, but this is not a clean solution. It is possible - to set default mixer values at the driver level — this - is accomplished by defining the appropriate values in - /boot/device.hints, e.g.: + hardcoded in the source code of the &man.pcm.4; driver. There + are many different applications and daemons that allow values to + be set for the mixer that are remembered between invocations, + but this is not a clean solution. It is possible to set default + mixer values at the driver level. This is accomplished by + defining the appropriate values in + /boot/device.hints, as seen in this + example: hint.pcm.0.vol="50" This will set the volume channel to a default value of - 50 when the &man.pcm.4; module is loaded. + 50 when the &man.pcm.4; module is + loaded. Chern Lee Contributed by MP3 Audio - MP3 (MPEG Layer 3 Audio) accomplishes near CD-quality sound, - leaving no reason to let your FreeBSD workstation fall short of - its offerings. + This section describes some MP3 + players available for &os;, how to rip audio CD tracks, and + how to encode and decode MP3s. MP3 Players - By far, the most popular X11 MP3 player is - XMMS (X Multimedia System). + A popular graphical MP3 player is + XMMS. Winamp skins can be used with XMMS since - the GUI is almost identical to that of Nullsoft's + the interface is almost identical to that of Nullsoft's Winamp. XMMS also has native plug-in support. XMMS can be installed from the multimedia/xmms port or package. XMMS's interface is intuitive, with a playlist, graphic equalizer, and more. Those familiar with Winamp will find XMMS simple to use. The audio/mpg123 port - is an alternative, command-line MP3 player. + provides an alternative, command-line MP3 + player. mpg123 can be run by specifying - the sound device and the MP3 file on the command line. - Assuming your audio device is - /dev/dsp1.0 and you want to play the - MP3 file Foobar-GreatestHits.mp3 - you would enter the following: + the sound device and the MP3 file on the + command line. Assuming the audio device is + /dev/dsp1.0 and the + MP3 file is + Foobar-GreatestHits.mp3, enter the + following to play the file: &prompt.root; mpg123 -a /dev/dsp1.0 Foobar-GreatestHits.mp3 High Performance MPEG 1.0/2.0/2.5 Audio Player for Layer 1, 2 and 3. Version 0.59r (1999/Jun/15). Written and copyrights by Michael Hipp. Uses code from various people. See 'README' for more! THIS SOFTWARE COMES WITH ABSOLUTELY NO WARRANTY! USE AT YOUR OWN RISK! Playing MPEG stream from Foobar-GreatestHits.mp3 ... MPEG 1.0 layer III, 128 kbit/s, 44100 Hz joint-stereo Ripping CD Audio Tracks - Before encoding a CD or CD track to MP3, the audio data on - the CD must be ripped onto the hard drive. This is done by - copying the raw CDDA (CD Digital Audio) data to WAV - files. + Before encoding a CD or CD track to + MP3, the audio data on the CD must be + ripped to the hard drive. This is done by copying the raw CD + Digital Audio (CDDA) data to + WAV files. - The cdda2wav tool, which is a part of - the sysutils/cdrtools + The cdda2wav tool, which is installed + with the sysutils/cdrtools suite, is used for ripping audio information from CDs and the information associated with them. With the audio CD in the drive, the following command can - be issued (as root) to rip an entire CD - into individual (per track) WAV files: + be issued as root to rip an entire CD + into individual (per track) WAV + files: &prompt.root; cdda2wav -D 0,1,0 -B - cdda2wav will support - ATAPI (IDE) CDROM drives. To rip from an IDE drive, specify - the device name in place of the SCSI unit numbers. For - example, to rip track 7 from an IDE drive: - - &prompt.root; cdda2wav -D /dev/acd0 -t 7 - The indicates the SCSI device 0,1,0, which corresponds to the output of cdrecord -scanbus. + cdda2wav will support ATAPI + (IDE) CDROM drives. To rip from an IDE drive, specify the + device name in place of the SCSI unit numbers. For example, + to rip track 7 from an IDE drive: + + &prompt.root; cdda2wav -D /dev/acd0 -t 7 + To rip individual tracks, make use of the - option as shown: + as shown: &prompt.root; cdda2wav -D 0,1,0 -t 7 This example rips track seven of the audio CDROM. To rip - a range of tracks, for example, track one to seven, specify a + a range of tracks, such as track one to seven, specify a range: &prompt.root; cdda2wav -D 0,1,0 -t 1+7 - The utility &man.dd.1; can also be used to extract audio - tracks on ATAPI drives, read for more information on - that possibility. + &man.dd.1; can also be used to extract audio tracks on + ATAPI drives, as described in . Encoding MP3s - Nowadays, the mp3 encoder of choice is - lame. - Lame can be found at - audio/lame in the ports - tree. + + Lame is a popular + MP3 encoder which can be installed from the + audio/lame port. Due to + licensing restrictions, a package is not available. - Using the ripped WAV files, the following command will - convert + The following command will convert the ripped + WAV files audio01.wav to audio01.mp3: &prompt.root; lame -h -b 128 \ --tt "Foo Song Title" \ --ta "FooBar Artist" \ --tl "FooBar Album" \ --ty "2001" \ --tc "Ripped and encoded by Foo" \ --tg "Genre" \ audio01.wav audio01.mp3 - 128 kbits seems to be the standard MP3 bitrate in - use. Many enjoy the higher quality 160, or 192. The higher - the bitrate, the more disk space the resulting MP3 will - consume--but the quality will be higher. The - option turns on the higher quality - but a little slower mode. The options beginning with - indicate ID3 tags, which usually contain - song information, to be embedded within the MP3 file. - Additional encoding options can be found by consulting the - lame man page. + 128 kbits is a standard MP3 + bitrate. The 160 and 192 bitrates provide higher quality. + The higher the bitrate, the larger the size of the resulting + MP3. turns on the + higher quality but a little slower mode. The + options beginning with indicate ID3 tags, + which usually contain song information, to be embedded within + the MP3 file. Additional encoding options + can be found in the lame manual + page. Decoding MP3s - In order to burn an audio CD from MP3s, they must be - converted to a non-compressed WAV format. Both + In order to burn an audio CD from MP3s, + they must first be converted to a non-compressed + WAV format. Both XMMS and - mpg123 support the output of MP3 - to an uncompressed file format. + mpg123 support the output of + MP3 to an uncompressed file format. Writing to Disk in XMMS: Launch XMMS. - Right-click on the window to bring up the + Right-click the window to bring up the XMMS menu. - Select Preference under + Select Preferences under Options. Change the Output Plugin to Disk Writer Plugin. Press Configure. - Enter (or choose browse) a directory to write the + Enter or browse to a directory to write the uncompressed files to. - Load the MP3 file into XMMS - as usual, with volume at 100% and EQ settings turned - off. + Load the MP3 file into + XMMS as usual, with volume at + 100% and EQ settings turned off. - Press Play — + Press Play. The XMMS will appear as if it is - playing the MP3, but no music will be heard. It is - actually playing the MP3 to a file. + playing the MP3, but no music will be + heard. It is actually playing the MP3 + to a file. - Be sure to set the default Output Plugin back to what - it was before in order to listen to MP3s again. + When finished, be sure to set the default Output + Plugin back to what it was before in order to listen to + MP3s again. Writing to stdout in mpg123: Run mpg123 -s audio01.mp3 > audio01.pcm - XMMS writes a file in the WAV - format, while mpg123 converts the - MP3 into raw PCM audio data. Both of these formats can be - used with cdrecord to create audio - CDs. You have to use raw PCM with &man.burncd.8;. If you - use WAV files, you will notice a small tick sound at the - beginning of each track, this sound is the header of the WAV - file. You can simply remove the header of a WAV file with - the utility SoX (it can be + XMMS writes a file in the + WAV format, while + mpg123 converts the + MP3 into raw PCM audio data. Both of these + formats can be used with cdrecord + to create audio CDs, whereas &man.burncd.8; requires a raw + Pulse-Code Modulation (PCM. When using + WAV files, there will be a small tick + sound at the beginning of each track. This sound is the + header of the WAV file. One can remove the + header with SoX, which can be installed from the audio/sox port or package): + role="package">audio/sox port or package: &prompt.user; sox -t wav -r 44100 -s -w -c 2 track.wav track.raw - Read for more information - on using a CD burner in FreeBSD. + Refer to for more + information on using a CD burner in &os;. Ross Lippert Contributed by Video Playback - Video playback is a very new and rapidly developing - application area. Be patient. Not everything is going to work - as smoothly as it did with sound. - - Before you begin, you should know the model of the video - card you have and the chip it uses. While + Before configuring video playback, determine the model + of the video card and the chip it uses. While &xorg; supports a wide variety of video cards, fewer give good playback performance. To obtain - a list of extensions supported by the X server using your card - use the command &man.xdpyinfo.1; while X11 is running. - - It is a good idea to have a short MPEG file which can be - treated as a test file for evaluating various players and - options. Since some DVD players will look for DVD media in - /dev/dvd by default, or have this device - name hardcoded in them, you might find it useful to make + a list of extensions supported by the + &xorg; server using the card, run + &man.xdpyinfo.1; while &xorg; is + running. + + It is a good idea to have a short MPEG test file for + evaluating various players and options. Since some DVD + applications look for DVD media in /dev/dvd by default, or have this + device name hardcoded in them, it might be useful to make symbolic links to the proper devices: &prompt.root; ln -sf /dev/acd0 /dev/dvd &prompt.root; ln -sf /dev/acd0 /dev/rdvd - Note that due to the nature of &man.devfs.5;, - manually created links like these will not persist if you reboot - your system. In order to create the symbolic links - automatically whenever you boot your system, add the following - lines to /etc/devfs.conf: + Due to the nature of &man.devfs.5;, manually created links + will not persist after a system reboot. In order to create the + symbolic links automatically when the system boots, add the + following lines to /etc/devfs.conf: link acd0 dvd link acd0 rdvd - Additionally, DVD decryption, which requires invoking - special DVD-ROM functions, requires write permission on the DVD - devices. + DVD decryption invokes special DVD-ROM functions and + requires write permission on the DVD devices. - To enhance the shared memory X11 interface, it is - recommended that the values of some &man.sysctl.8; variables - should be increased: + To enhance the shared memory + &xorg; interface, it is + recommended to increase the values of these &man.sysctl.8; + variables: kern.ipc.shmmax=67108864 kern.ipc.shmall=32768 Determining Video Capabilities XVideo SDL DGA - There are several possible ways to display video under X11. - What will really work is largely hardware dependent. Each - method described below will have varying quality across - different hardware. Secondly, the rendering of video in X11 - is a topic receiving a lot of attention lately, and with each - version of &xorg;, there may be - significant improvement. + There are several possible ways to display video under + &xorg;. What works is largely + hardware dependent. Each method described below will have + varying quality across different hardware. - A list of common video interfaces: + Common video interfaces include: - X11: normal X11 output using shared memory. + &xorg;: normal output using + shared memory. - XVideo: an extension to the X11 interface which supports - video in any X11 drawable. + XVideo: an extension to the + &xorg; interface which supports + video in any drawable object. - SDL: the Simple Directmedia Layer. + SDL: the Simple Directmedia + Layer. - DGA: the Direct Graphics Access. + DGA: the Direct Graphics + Access. SVGAlib: low level console graphics layer. XVideo &xorg; has an extension called - XVideo (aka Xvideo, aka Xv, aka xv) which - allows video to be directly displayed in drawable objects - through a special acceleration. This extension provides very + XVideo, also known as Xvideo, Xv, and xv. + It allows video to be directly displayed in drawable objects + through a special acceleration. This extension provides good quality playback even on low-end machines. To check whether the extension is running, use xvinfo: &prompt.user; xvinfo - XVideo is supported for your card if the result looks + XVideo is supported for the card if the result looks like: X-Video Extension version 2.2 screen #0 Adaptor #0: "Savage Streams Engine" number of ports: 1 port base: 43 operations supported: PutImage supported visuals: depth 16, visualID 0x22 depth 16, visualID 0x23 number of attributes: 5 "XV_COLORKEY" (range 0 to 16777215) client settable attribute client gettable attribute (current value is 2110) "XV_BRIGHTNESS" (range -128 to 127) client settable attribute client gettable attribute (current value is 0) "XV_CONTRAST" (range 0 to 255) client settable attribute client gettable attribute (current value is 128) "XV_SATURATION" (range 0 to 255) client settable attribute client gettable attribute (current value is 128) "XV_HUE" (range -180 to 180) client settable attribute client gettable attribute (current value is 0) maximum XvImage size: 1024 x 1024 Number of image formats: 7 id: 0x32595559 (YUY2) guid: 59555932-0000-0010-8000-00aa00389b71 bits per pixel: 16 number of planes: 1 type: YUV (packed) id: 0x32315659 (YV12) guid: 59563132-0000-0010-8000-00aa00389b71 bits per pixel: 12 number of planes: 3 type: YUV (planar) id: 0x30323449 (I420) guid: 49343230-0000-0010-8000-00aa00389b71 bits per pixel: 12 number of planes: 3 type: YUV (planar) id: 0x36315652 (RV16) guid: 52563135-0000-0000-0000-000000000000 bits per pixel: 16 number of planes: 1 type: RGB (packed) depth: 0 red, green, blue masks: 0x1f, 0x3e0, 0x7c00 id: 0x35315652 (RV15) guid: 52563136-0000-0000-0000-000000000000 bits per pixel: 16 number of planes: 1 type: RGB (packed) depth: 0 red, green, blue masks: 0x1f, 0x7e0, 0xf800 id: 0x31313259 (Y211) guid: 59323131-0000-0010-8000-00aa00389b71 bits per pixel: 6 number of planes: 3 type: YUV (packed) id: 0x0 guid: 00000000-0000-0000-0000-000000000000 bits per pixel: 0 number of planes: 0 type: RGB (packed) depth: 1 red, green, blue masks: 0x0, 0x0, 0x0 - Also note that the formats listed (YUV2, YUV12, etc) are - not present with every implementation of XVideo and their - absence may hinder some players. + The formats listed, such as YUV2 and YUV12, are not present + with every implementation of XVideo and their absence may hinder + some players. If the result looks like: X-Video Extension version 2.2 screen #0 no adaptors present - Then XVideo is probably not supported for your card. - - If XVideo is not supported for your card, this only means - that it will be more difficult for your display to meet the - computational demands of rendering video. Depending on your - video card and processor, though, you might still be able to - have a satisfying experience. You should probably read about - ways of improving performance in the advanced reading . + XVideo is probably not supported for the card. This means + that it will be more difficult for the display to meet the + computational demands of rendering video. Depending on the + video card and processor, one might still be able to have a + satisfying experience. Simple Directmedia Layer The Simple Directmedia Layer, SDL, is a porting layer for many operating systems allowing cross-platform applications to be developed which make efficient use of sound and graphics. The SDL layer provides a low-level abstraction to the hardware which can sometimes be - more efficient than the X11 interface. + more efficient than the &xorg; + interface. - The SDL can be found at devel/sdl12. + SDL can be installed using the devel/sdl12 package or port. Direct Graphics Access - Direct Graphics Access is an X11 extension which allows - a program to bypass the X server and directly alter the - framebuffer. Because it relies on a low level memory mapping to - effect this sharing, programs using it must be run as + DGA is an + &xorg; extension which allows a + program to bypass the &xorg; server + and directly alter the framebuffer. Because it relies on a low + level memory mapping, programs using it must be run as root. - The DGA extension can be tested and benchmarked by - &man.dga.1;. When dga is running, it - changes the colors of the display whenever a key is pressed. To - quit, use q. + The DGA extension can be tested and + benchmarked using &man.dga.1;. When dga is + running, it changes the colors of the display whenever a key is + pressed. To quit, press q. Ports and Packages Dealing with Video video ports video packages - This section discusses the software available from the - FreeBSD Ports Collection which can be used for video playback. - Video playback is a very active area of software development, - and the capabilities of various applications are bound to - diverge somewhat from the descriptions given here. + This section introduces some of the software available from + the &os; Ports Collection which can be used for video + playback. - Firstly, it is important to know that many of the video - applications which run on FreeBSD were developed as Linux - applications. Many of these applications are still - beta-quality. Some of the problems that you may encounter with - video packages on FreeBSD include: + Many of the video applications which run on &os; were + developed as &linux; applications. Many of these applications + are still beta-quality. Some of the problems commonly + encountered with video packages on &os; include: An application cannot playback a file which another application produced. An application cannot playback a file which the application itself produced. The same application on two different machines, rebuilt on each machine for that machine, plays back the same file differently. - A seemingly trivial filter like rescaling of the image - size results in very bad artifacts from a buggy rescaling + A seemingly trivial filter, like rescaling of the image + size, results in bad artifacts from a buggy rescaling routine. An application frequently dumps core. Documentation is not installed with the port and can be found either on the web or under the port's work directory. - Many of these applications may also exhibit - Linux-isms. That is, there may be issues - resulting from the way some standard libraries are - implemented in the Linux distributions, or some features of - the Linux kernel which have been assumed by the authors of the - applications. These issues are not always noticed and worked - around by the port maintainers, which can lead to problems like - these: + Many applications may also exhibit + &linux;-isms. There may be issues resulting from + the way some standard libraries are implemented in the &linux; + distributions, or some features of the &linux; kernel which have + been assumed by the authors of the applications. These issues + are not always noticed and worked around by the port + maintainers, which can lead to problems like these: The use of /proc/cpuinfo to detect processor characteristics. A misuse of threads which causes a program to hang upon completion instead of truly terminating. - Software not yet in the FreeBSD Ports Collection - which is commonly used in conjunction with the - application. + Relies on software which is not yet available in the + &os; Ports Collection. - So far, these application developers have been cooperative - with port maintainers to minimize the work-arounds needed for - port-ing. - MPlayer - MPlayer is a recently developed - and rapidly developing video player. The goals of the - MPlayer team are speed and - flexibility on Linux and other Unices. The project was - started when the team founder got fed up with bad playback - performance on then available players. Some would say that - the graphical interface has been sacrificed for a streamlined - design. However, once you get used to the command line - options and the key-stroke controls, it works very - well. + MPlayer is a command-line video + player with an optional graphical interface which aims to + provide speed and flexibility. This application, as well as + other graphical front-ends, is available from the &os; Ports + Collection. Building MPlayer MPlayer making - MPlayer resides in multimedia/mplayer. - MPlayer performs a variety of - hardware checks during the build process, resulting in a - binary which will not be portable from one system to - another. Therefore, it is important to build it from - ports and not to use a binary package. Additionally, a - number of options can be specified in the - make command line, as described in the - Makefile and at the start of the - build: + MPlayer is available as a + package or port in multimedia/mplayer. Several + compile options are available and a variety of hardware + checks occur during the build process. For these reasons, + some users prefer to build the port rather than install the + package. The available options will be displayed in a + menu after these commands are input: &prompt.root; cd /usr/ports/multimedia/mplayer -&prompt.root; make -N - O - T - E - -Take a careful look into the Makefile in order -to learn how to tune mplayer towards you personal preferences! -For example, -make WITH_GTK1 -builds MPlayer with GTK1-GUI support. -If you want to use the GUI, you can either install -/usr/ports/multimedia/mplayer-skins -or download official skin collections from -http://www.mplayerhq.hu/homepage/dload.html - - The default port options should be sufficient for most - users. However, if you need the XviD codec, you have to - specify the WITH_XVID option in the - command line. The default DVD device can also be defined - with the WITH_DVD_DEVICE option, by - default /dev/acd0 will be used. - - As of this writing, the - MPlayer port will build its HTML - documentation and two executables, - mplayer, and mencoder, - which is a tool for re-encoding video. - - The HTML documentation for - MPlayer is very informative. - If the reader finds the information on video hardware and - interfaces in this chapter lacking, the - MPlayer documentation is a very - thorough supplement. You should definitely take the time - to read the MPlayer documentation - if you are looking for information about video support in - &unix;. +&prompt.root; make + + The menu options should be reviewed to determine the + type of support to compile into the port. If an option is + not selected, MPlayer will not be + able to display that type of video format. Use the arrow + keys and spacebar to select the required formats. When + finished, press Enter to continue the port + compile and installation. + + By default, this package or port will build the + mplayer command line utility and the + gmplayer graphical utility. To encode + videos, install the multimedia/mencoder port. Due + to licensing restrictions, a package is not available for + MEncoder. Using MPlayer MPlayer use - Any user of MPlayer must set - up a .mplayer subdirectory of her - home directory. To create this necessary subdirectory, - you can type the following: - - &prompt.user; cd /usr/ports/multimedia/mplayer -&prompt.user; make install-user + The first time MPlayer is + run, it will create ~/.mplayer in the user's + home directory. This subdirectory contains default versions + of the user-specific configuration files. - The command options for mplayer are - listed in the manual page. For even more detail there is - HTML documentation. In this section, we will describe only - a few common uses. + This section describes only a few common uses. Refer + to the mplayer manual page for a complete + description of its numerous options. - To play a file, such as + To play the file testfile.avi, - through one of the various video interfaces set the - option: + specify the video interfaces with + : &prompt.user; mplayer -vo xv testfile.avi &prompt.user; mplayer -vo sdl testfile.avi &prompt.user; mplayer -vo x11 testfile.avi &prompt.root; mplayer -vo dga testfile.avi &prompt.root; mplayer -vo 'sdl:dga' testfile.avi It is worth trying all of these options, as their relative performance depends on many factors and will vary significantly with hardware. - To play from a DVD, replace the + To play a DVD, replace the testfile.avi with where + DEVICE, where N is the title number to play and DEVICE is the device node for the DVD-ROM. For example, to play - title 3 from /dev/dvd: + title 3 from /dev/dvd: &prompt.root; mplayer -vo xv dvd://3 -dvd-device /dev/dvd The default DVD device can be defined during the build - of the MPlayer port via the - WITH_DVD_DEVICE option. By default, - this device is /dev/acd0. More - details can be found in the port - Makefile. + of the MPlayer port by + including the + WITH_DVD_DEVICE=/path/to/desired/device + option. By default, the device is + /dev/acd0. More details can be found + in the port's + Makefile.options. - To stop, pause, advance and so on, consult the - keybindings, which are output by running mplayer - -h or read the manual page. + To stop, pause, advance, and so on, consult the + keybindings, which are displayed by running mplayer + -h, or read the manual page. - Additional important options for playback are: - which engages the fullscreen mode - and which helps + Additional playback options include + , which engages fullscreen mode, + and , which helps performance. - In order for the mplayer command line to not become too - large, the user can create a file - .mplayer/config and set default options - there: + Each user can add commonly used options to their + ~/.mplayer/config like so: + vo=xv fs=yes zoom=yes - Finally, mplayer can be used to rip a - DVD title into a .vob file. To dump - out the second title from a DVD, type this: + mplayer can be used to rip a DVD + title to a .vob. To dump the second + title from a DVD: &prompt.root; mplayer -dumpstream -dumpfile out.vob dvd://2 -dvd-device /dev/dvd The output file, out.vob, will be MPEG and can be manipulated by the other packages described in this section. + The MPlayer + documentation is technically informative and + should be consulted by anyone wishing to obtain a high level + of expertise with &unix; video. The + MPlayer mailing list is hostile + to anyone who has not bothered to read the documentation, so + before making a bug report, read the documentation + first. + - mencoder + <application>MEncoder</application> mencoder - Before using mencoder it is a good - idea to familiarize yourself with the options from the HTML - documentation. There is a manual page, but it is not very - useful without the HTML documentation. There are - innumerable ways to improve quality, lower bitrate, and - change formats, and some of these tricks may make the - difference between good or bad performance. Here are a - couple of examples to get you going. First a simple - copy: + Before using mencoder, it is a good + idea to become familiar with the options described in the + HTML + documentation. There are innumerable ways to + improve quality, lower bitrate, and change formats, and some + of these options may make the difference between good or bad + performance. Improper combinations of command line options + can yield output files that are unplayable even by + mplayer. + + Here is an example of a simple copy: &prompt.user; mencoder input.avi -oac copy -ovc copy -o output.avi - Improper combinations of command line options can yield - output files that are unplayable even by - mplayer. Thus, if you just want to rip - to a file, stick to the in + To rip to a file, use with mplayer. To convert input.avi - to the MPEG4 codec with MPEG3 audio encoding (audio/lame is required): + to the MPEG4 codec with MPEG3 audio encoding, first install + the audio/lame port. + Due to licensing restrictions, a package is not available. + Once installed, type: &prompt.user; mencoder input.avi -oac mp3lame -lameopts br=192 \ -ovc lavc -lavcopts vcodec=mpeg4:vhq -o output.avi - This has produced output playable by - mplayer and + This will produce output playable by applications such + as mplayer and xine. input.avi can be replaced with and run as root - to re-encode a DVD title directly. Since you are likely - to be dissatisfied with your results the first time around, - it is recommended you dump the title to a file and work on - the file. + to re-encode a DVD title directly. Since it may take a few + tries to get the desired result, it is recommended to dump + the title to a file and to work on the file. - The xine Video Player - - The xine video player is a - project of wide scope aiming not only at being an all in one - video solution, but also in producing a reusable base library - and a modular executable which can be extended with plugins. - It comes both as a package and as a port, multimedia/xine. - - The xine player - is still very rough around the edges, but it is clearly off - to a good start. In practice, xine - requires either a fast CPU with a fast video card, or support - for the XVideo extension. The GUI is usable, but a bit - clumsy. - - As of this writing, there is no input module shipped with - xine which will play CSS encoded - DVDs. There are third party builds which do have modules for - this built in them, but none of these are in the FreeBSD Ports - Collection. + The <application>xine</application> Video Player + + xine is a video player with a + reusable base library and a modular executable which can be + extended with plugins. It can be installed using the + multimedia/xine package or + port. - Compared to MPlayer, - xine does more for the user, but - at the same time, takes some of the more fine-grained control - away from the user. The xine video + In practice, xine requires + either a fast CPU with a fast video card, or support for the + XVideo extension. The xine video player performs best on XVideo interfaces. - By default, xine player will - start up in a graphical user interface. The menus can then - be used to open a specific file: + By default, the xine player + starts a graphical user interface. The menus can then be used + to open a specific file. + + Alternatively, xine may be + invoked to play a file immediately without the graphical + interface: &prompt.user; xine Alternatively, it may be invoked to play a file immediately without the GUI with the command: &prompt.user; xine -g -p mymovie.avi + The + xine HOWTO contains a chapter on performance + improvement which is general to all players. - The transcode Utilities - - The software transcode is not a - player, but a suite of tools for re-encoding video and audio - files. With transcode, one has the - ability to merge video files, repair broken files, using - command line tools with stdin/stdout - stream interfaces. - - A great number of options can be specified during the - build from the multimedia/transcode port, we - recommend the following command line to build - transcode: - - &prompt.root; make WITH_OPTIMIZED_CFLAGS=yes WITH_LIBA52=yes WITH_LAME=yes WITH_OGG=yes \ -WITH_MJPEG=yes -DWITH_XVID=yes - - The proposed settings should be sufficient for most - users. - - To illustrate transcode capacities, one - example to show how to convert a DivX file into a PAL MPEG-1 - file (PAL VCD): + The <application>transcode</application> + Utilities + + transcode provides a suite of + tools for re-encoding video and audio files. + transcode can be used to merge + video files or repair broken files using command line tools + with stdin/stdout stream + interfaces. + + transcode can be installed + using the multimedia/transcode package or + port. Many users prefer to compile the port as it provides a + menu of compile options for specifying the support and codecs + to compile in. If an option is not selected, + transcode will not be able to + encode that format. Use the arrow keys and spacebar to select + the required formats. When finished, press + Enter to continue the port compile and + installation. + + This example demonstrates how to convert a DivX file into + a PAL MPEG-1 file (PAL VCD): &prompt.user; transcode -i input.avi -V --export_prof vcd-pal -o output_vcd &prompt.user; mplex -f 1 -o output_vcd.mpg output_vcd.m1v output_vcd.mpa The resulting MPEG file, output_vcd.mpg, is ready to be played with MPlayer. - You could even burn the file on a CD-R media to create a Video - CD, in this case you will need to install and use both multimedia/vcdimager and sysutils/cdrdao programs. - There is a manual page for transcode, but - you should also consult the In addition to the manual page for + transcode, refer to the transcode wiki for further information and examples. - - - Further Reading - - The various video software packages for FreeBSD are - developing rapidly. It is quite possible that in the near - future many of the problems discussed here will have been - resolved. In the mean time, those who want to get the very - most out of FreeBSD's A/V capabilities will have to cobble - together knowledge from several FAQs and tutorials and use a - few different applications. This section exists to give the - reader pointers to such additional information. - - The MPlayer - documentation is very technically informative. - These documents should probably be consulted by anyone wishing - to obtain a high level of expertise with &unix; video. The - MPlayer mailing list is hostile to - anyone who has not bothered to read the documentation, so if - you plan on making bug reports to them, RTFM. - - The - xine HOWTO contains a chapter on performance improvement - which is general to all players. - - Finally, there are some other promising applications which - the reader may try: - - - - Avifile - which is also a port multimedia/avifile. - - - - Ogle - which is also a port multimedia/ogle. - - - - Xtheater - - - - multimedia/dvdauthor, an open - source package for authoring DVD content. - - - - - Josef El-Rayes Original contribution by Marc Fonvieille Enhanced and adapted by Setting Up TV Cards TV cards Introduction - TV cards allow you to watch broadcast or cable TV on your - computer. Most of them accept composite video via an RCA or - S-video input and some of these cards come with a FM radio - tuner. + TV cards allow can be used to watch broadcast or cable TV on + a computer. Most cards accept composite video via an RCA or + S-video input and some cards include a FM radio tuner. &os; provides support for PCI-based TV cards using a Brooktree Bt848/849/878/879 or a Conexant CN-878/Fusion 878a - Video Capture Chip with the &man.bktr.4; driver. You must - also ensure the board comes with a supported tuner, consult - the &man.bktr.4; manual page for a list of supported - tuners. + video capture chip with the &man.bktr.4; driver. Ensure the + board comes with a supported tuner. Consult &man.bktr.4; for a + list of supported tuners. - Adding the Driver + Loading the Driver - To use your card, you will need to load the &man.bktr.4; - driver, this can be done by adding the following line to the - /boot/loader.conf file like this: + In order to use the card, the &man.bktr.4; driver must be + loaded. To automate this at boot time, add the following line + to /boot/loader.conf: bktr_load="YES" - Alternatively, you may statically compile the support for - the TV card in your kernel, in that case add the following - lines to your kernel configuration: + Alternatively, one can statically compile support for + the TV card into a custom kernel. In that case, add the + following lines to the custom kernel configuration + file: device bktr device iicbus device iicbb device smbus - These additional device drivers are necessary because - of the card components being interconnected via an I2C bus. - Then build and install a new kernel. + These additional devices are necessary as the card + components are interconnected via an I2C bus. Then, build and + install a new kernel. - Once the support was added to your system, you have to - reboot your machine. During the boot process, your TV card - should show up, like this: + To test the driver, reboot the system. The TV card + should appear in the boot messages, as seen in this + example: bktr0: <BrookTree 848A> mem 0xd7000000-0xd7000fff irq 10 at device 10.0 on pci0 iicbb0: <I2C bit-banging driver> on bti2c0 iicbus0: <Philips I2C bus> on iicbb0 master-only iicbus1: <Philips I2C bus> on iicbb0 master-only smbus0: <System Management Bus> on bti2c0 bktr0: Pinnacle/Miro TV, Philips SECAM tuner. - Of course these messages can differ according to your - hardware. However you should check if the tuner is correctly - detected; it is still possible to override some of the - detected parameters with &man.sysctl.8; MIBs and kernel - configuration file options. For example, if you want to force - the tuner to a Philips SECAM tuner, you should add the - following line to your kernel configuration file: + The messages will differ according to the hardware. Check + the messages to determine if the tuner is correctly detected. + It is still possible to override some of the detected + parameters with &man.sysctl.8; MIBs and kernel configuration + file options. For example, to force the tuner to a Philips + SECAM tuner, add the following line to a custom kernel + configuration file: options OVERRIDE_TUNER=6 - or you can directly use &man.sysctl.8;: + or, use &man.sysctl.8;: &prompt.root; sysctl hw.bt848.tuner=6 - See the &man.bktr.4; manual page and the - /usr/src/sys/conf/NOTES file for more + Refer to &man.bktr.4; and + /usr/src/sys/conf/NOTES for more details on the available options. Useful Applications - To use your TV card you need to install one of the - following applications: + To use the TV card, install one of the following + applications: multimedia/fxtv provides TV-in-a-window and image/audio/video capture capabilities. multimedia/xawtv - is also a TV application, with the same features as - fxtv. - - - misc/alevt decodes - and displays Videotext/Teletext. - - - audio/xmradio, an - application to use the FM radio tuner coming with some - TV cards. + is another TV application with similar features. - audio/wmtune, a - handy desktop application for radio tuners. + audio/xmradio + provides an application for using the FM radio tuner of a + TV card. More applications are available in the &os; Ports Collection. Troubleshooting - If you encounter any problem with your TV card, you should - check at first if the video capture chip and the tuner are - really supported by the &man.bktr.4; driver and if you used - the right configuration options. For more support and various - questions about your TV card you may want to contact and use - the archives of the &a.multimedia.name; mailing list. + If any problems are encountered with the TV card, + check that the video capture chip and the tuner are + supported by &man.bktr.4; and that the right configuration + options were used. For more support and various questions + about TV cards, refer to the archives of the + &a.multimedia.name; mailing list. MythTV - MythTV is an open source PVR software - project. + MythTV is a popular, open source PVR + application. This section demonstrates how to install and + setup MythTV on &os;. Refer to the MythTV wiki for + more information on how to use MythTV. - It is well-known in the &linux; world as a complex - application with many dependencies, and therefore difficult to - install. The &os; ports system simplifies much of the process, - but some components must be set up manually. This section is - intended to help and guide in setting up MythTV. + MythTV requires a frontend and a backend; however, + it allows the user to have the frontend and backend on + different machines. + + For the frontend, multimedia/mythtv-frontend is + required, as well as an X server, which can be found in + x11/xorg. Ideally, the + frontend computer also has a video card that supports XvMC and, + optionally, a LIRC-compatible remote. + + For the backend, multimedia/mythtv is required, + along with the &mysql; database server. Optionally a tuner + and storage for any recorded data. The &mysql; package should + be automatically installed as a dependency when installing + multimedia/mythtv. Hardware - MythTV is designed to utilise MythTV is designed to utilize V4L to access video input devices such as encoders and tuners. At this time, MythTV works best with USB DVB-S/C/T cards supported by multimedia/webcamd because - webcamd provides a multimedia/webcamd, as it provides + a V4L userland application. Any DVB card supported by webcamd should - work with MythTV, but a list of known working cards can be + work with MythTV. A list of known working cards can be found here. - There are also drivers available for Hauppauge cards in the - following packages: multimedia/pvr250 and multimedia/pvrxxx, but they provide a non-standard driver interface that does not work - with versions of MythTV greater than 0.23. + with versions of MythTV greater than 0.23. Due to licensing + restrictions, no packages are available and these two ports + must be compiled. - HTPC - contains a list of all available The HTPC + wiki page contains a list of all available DVB drivers. - - Dependencies - - Being flexible and modular, MythTV allows the user to - have the frontend and backend on different machines. - - For the frontend, multimedia/mythtv-frontend is - required, as well as an X server, which can be found in - x11/xorg. Ideally, the - frontend computer also has a video card that supports XvMC and, - optionally, a LIRC-compatible - remote. - - For the backend, multimedia/mythtv is required, - as well as a &mysql; database, and optionally a tuner and - storage for recordings. The &mysql; package should be - automatically installed as a dependency when installing - multimedia/mythtv. - - Setting up MythTV - To install MythTV, use the following steps. First, - install MythTV from the &os; Ports collection: + To install the MythTV port: &prompt.root; cd /usr/ports/multimedia/mythtv &prompt.root; make install - Set up the MythTV database: + Once installed, set up the MythTV database: &prompt.root; mysql -uroot -p < /usr/local/share/mythtv/database/mc.sql Configure the backend: &prompt.root; mythtv-setup Start the backend: - &prompt.root; echo 'mythbackend_enable="YES"' >> /etc/rc.conf + &prompt.root; echo 'mythbackend_enable="YES"' >> /etc/rc.conf &prompt.root; service mythbackend start Marc Fonvieille Written by Image Scanners image scanners - - Introduction - - In &os;, access to image scanners is provided - by the SANE (Scanner Access Now - Easy) API available through the &os; Ports - Collection. SANE will also use - some &os; device drivers to access to the scanner - hardware. - - &os; supports both SCSI and USB scanners. Be sure your - scanner is supported by SANE prior - to performing any configuration. - SANE has a supported - devices list that can provide you with information - about the support for a scanner and its status. - + In &os;, access to image scanners is provided by the + SANE (Scanner Access Now Easy) + API available through the &os; Ports + Collection. SANE will also use + some &os; device drivers to provide access to the scanner + hardware. + + &os; supports both SCSI and USB scanners. Be sure the + scanner is supported by SANE prior + to performing any configuration. Refer to the + supported devices list for more information about supported + scanners. Kernel Configuration - As mentioned above both SCSI and USB interfaces are - supported. According to your scanner interface, different - device drivers are required. + Both SCSI and USB interfaces are supported. Depending + upon the scanner interface, different device drivers are + required. USB Interface The GENERIC kernel by default includes the device drivers needed to support USB scanners. - Should you decide to use a custom kernel, be sure that the - following lines are present in your kernel configuration + Users with a custom kernel should ensure that the following + lines are present in the custom kernel configuration file: device usb device uhci device ohci device ehci - After rebooting with the correct kernel, - plug in your USB scanner. A - line showing the detection of your - scanner should appear in the system message buffer - (&man.dmesg.8;): + Plug in the USB scanner. Use &man.dmesg.8; to determine + whether the scanner appears in the system message + buffer: ugen0.2: <EPSON> at usbus0 - These messages show that our scanner is using - either /dev/ugen0.2 - as device node. For this example, a + These messages indicate that the scanner is using + either /dev/ugen0.2 or + /dev/uscanner0, depending on the &os; + version. For this example, a &epson.perfection; 1650 USB scanner was used. SCSI Interface - If your scanner comes with a SCSI interface, it is - important to know which SCSI controller board you will use. - According to the SCSI chipset used, you will have to tune - your kernel configuration file. The - GENERIC kernel supports the most common - SCSI controllers. Be sure to read the - NOTES file - and add the correct line to your kernel - configuration file. In addition to the SCSI adapter driver, - you need to have the following lines in your kernel - configuration file: + If the scanner uses a SCSI interface, it is important to + know which SCSI controller board it will use. Depending + upon the SCSI chipset, a custom kernel configuration file + may be needed. The GENERIC kernel + supports the most common SCSI controllers. Refer to + /usr/src/sys/conf/NOTES to determine + the correct line to add to a custom kernel configuration + file. In addition to the SCSI adapter driver, the following + lines are needed in the kernel configuration file: device scbus device pass - Once your kernel has been properly compiled and - installed, you should be able to see the devices in the - system message buffer, when booting: + Verify that the device is displayed in the system + message buffer: pass2 at aic0 bus 0 target 2 lun 0 pass2: <AGFA SNAPSCAN 600 1.10> Fixed Scanner SCSI-2 device pass2: 3.300MB/s transfers - If your scanner was not powered-on at system boot, it + If the scanner was not powered-on at system boot, it is still possible to manually force the detection by performing a SCSI bus scan with the &man.camcontrol.8; command: &prompt.root; camcontrol rescan all Re-scan of bus 0 was successful Re-scan of bus 1 was successful Re-scan of bus 2 was successful Re-scan of bus 3 was successful - Then the scanner will appear in the SCSI devices + The scanner should now appear in the SCSI devices list: &prompt.root; camcontrol devlist <IBM DDRS-34560 S97B> at scbus0 target 5 lun 0 (pass0,da0) <IBM DDRS-34560 S97B> at scbus0 target 6 lun 0 (pass1,da1) <AGFA SNAPSCAN 600 1.10> at scbus1 target 2 lun 0 (pass3) <PHILIPS CDD3610 CD-R/RW 1.00> at scbus2 target 0 lun 0 (pass2,cd0) - More details about SCSI devices are available in the - &man.scsi.4; and &man.camcontrol.8; manual pages. + Refer to &man.scsi.4; and &man.camcontrol.8; for more + details about SCSI devices on &os;. SANE Configuration - The SANE system is - split in two parts: the backends (graphics/sane-backends) and the + The SANE system is split in two + parts: the backends (graphics/sane-backends) and the frontends (graphics/sane-frontends). The - backends part provides access to the scanner itself. The + role="package">graphics/sane-frontends). The + backends provide access to the scanner. The SANE's supported - devices list specifies which backend will support your - image scanner. It is mandatory to determine the correct - backend for your scanner if you want to be able to use your - device. The frontends part provides the graphical scanning - interface (xscanimage). - - The first step is to install the supported + devices list specifies which backend will support the + image scanner. The correct backend is needed in order to use + the scanner. The frontends provide the graphical scanning + interface, xscanimage. + + After installing the graphics/sane-backends port or - package. Then, use the sane-find-scanner - command to check the scanner detection by the + package, use sane-find-scanner to check the + scanner detection by the SANE system: &prompt.root; sane-find-scanner -q found SCSI scanner "AGFA SNAPSCAN 600 1.10" at /dev/pass3 - The output will show the interface type of the scanner and - the device node used to attach the scanner to the system. The - vendor and the product model may not appear, it is not - important. + The output should show the interface type of the scanner + and the device node used to attach the scanner to the system. + The vendor and the product model may or may not appear. - Some USB scanners require you to load a firmware, this - is explained in the backend manual page. You should also - read &man.sane-find-scanner.1; and &man.sane.7; manual - pages. + Some USB scanners require firmware to be loaded. Refer + to &man.sane-find-scanner.1; and &man.sane.7; for + details. - Now we have to check if the scanner will be identified - by a scanning frontend. By default, the - SANE backends comes with a command - line tool called &man.scanimage.1;. This command allows you - to list the devices and to perform an image acquisition from - the command line. The option is used to - list the scanner devices: + Next, check if the scanner will be identified by a + scanning frontend. By default, the + SANE backends come with a command + line tool called &man.scanimage.1;. This command can be used + to list the devices and perform an image acquisition. Use + to list the scanner devices: &prompt.root; scanimage -L device `snapscan:/dev/pass3' is a AGFA SNAPSCAN 600 flatbed scanner - Or, for example with the USB scanner used in the Here is the output for the USB scanner used in : &prompt.root; scanimage -L device 'epson2:libusb:/dev/usb:/dev/ugen0.2' is a Epson GT-8200 flatbed scanner - This output comes from a &os; 8.X system, the - 'epson2:libusb:/dev/usb:/dev/ugen0.2' item - gives us the backend name (epson2) and the - device node (/dev/ugen0.2) used by our + In this output, + 'epson2:libusb:/dev/usb:/dev/ugen0.2' is + the backend name (epson2) and the device + node (/dev/ugen0.2) used by the scanner. No output or a message saying that no scanners were identified indicates that &man.scanimage.1; is unable to - identify the scanner. If this happens, you will need to - edit the backend configuration file and define the scanner - device used. The /usr/local/etc/sane.d/ - directory contains all backend configuration files. This - identification problem does appear with certain USB - scanners. + and define the scanner device used. - For example, with the USB scanner used in the , under &os; 8.X the - scanner is perfectly detected and working but under prior - versions of &os; (where &man.uscanner.4; driver is used) - sane-find-scanner gives us the following - information: + In the above example, the USB scanner is perfectly + detected and working. - &prompt.root; sane-find-scanner -q -found USB scanner (UNKNOWN vendor and product) at device /dev/uscanner0 - - The scanner is correctly detected, it uses the USB - interface and is attached to the - /dev/uscanner0 device node. We can - now check if the scanner is correctly identified: + To determine if the scanner is correctly + identified: &prompt.root; scanimage -L No scanners were identified. If you were expecting something different, check that the scanner is plugged in, turned on and detected by the sane-find-scanner tool (if appropriate). Please read the documentation which came with this software (README, FAQ, manpages). - Since the scanner is not identified, we will need to edit - the /usr/local/etc/sane.d/epson2.conf - file. The scanner model used was the - &epson.perfection; 1650, so we know the scanner will use - the epson2 backend. Be sure to read the - help comments in the backends configuration files. Line - changes are quite simple: comment out all lines that have the - wrong interface for your scanner (in our case, we will comment + Since the scanner is not identified, edit + /usr/local/etc/sane.d/epson2.conf. In + this example, the scanner model is + &epson.perfection; 1650 and it uses the + epson2 backend. When editing, read the + help comments in the backend configuration file. Line + changes are simple: comment out all lines that have the + wrong interface for the scanner. In this example, comment out all lines starting with the word scsi - as our scanner uses the USB interface), then add at the end - of the file a line specifying the interface and the device - node used. In this case, we add the following line: + as the scanner uses the USB interface. Then, at the end + of the file, add a line specifying the interface and the + device node used. In this case, add the following + line: usb /dev/uscanner0 - Please be sure to read the comments provided in the - backend configuration file as well as the backend manual page - for more details and correct syntax to use. We can now verify - if the scanner is identified: + Save the edits and verify that the scanner is + identified: &prompt.root; scanimage -L device `epson:/dev/uscanner0' is a Epson GT-8200 flatbed scanner - Our USB scanner has been identified. It is not important - if the brand and the model do not match the scanner. The - key item to be concerned with is the - `epson:/dev/uscanner0' field, which give - us the right backend name and the right device node. + The `epson:/dev/uscanner0' field now + gives the right backend name and the device node. - Once the scanimage -L command is able - to see the scanner, the configuration is complete. The device - is now ready to scan. - - While &man.scanimage.1; does allow us to perform an - image acquisition from the command line, it is preferable to - use a graphical user interface to perform image scanning. - SANE offers a simple but efficient - graphical interface: xscanimage - (graphics/sane-frontends). - - Xsane (graphics/xsane) is another popular - graphical scanning frontend. This frontend offers advanced - features such as various scanning mode (photocopy, fax, etc.), - color correction, batch scans, etc. Both of these applications - are usable as a GIMP plugin. + Once scanimage -L sees the scanner, the + configuration is complete and the device is now ready to + scan. + + While &man.scanimage.1; can be used to perform an image + acquisition from the command line, it is often preferable to + use a graphical interface to perform image scanning. The + graphics/sane-frontends + package or port installs a simple but efficient graphical + interface, xscanimage. + + Xsane, which is installed with + the graphics/xsane package + or port, is another popular graphical scanning frontend. It + offers advanced features such as various scanning modes, color + correction, and batch scans. Both of these applications are + usable as a GIMP plugin. Giving Other Users Access to the Scanner - All previous operations have been done with - root privileges. You may however, need - other users to have access to the scanner. The user will need + In order to have access to the scanner, a user needs read and write permissions to the device node used by the - scanner. As an example, our USB scanner uses the device node - /dev/ugen0.2 which is in fact just a - symlink to the real device node called - /dev/usb/0.2.0 (a quick look at the - contents of the /dev - directory will confirm it). Both, the symlink and the - device node, are owned respectively by the - wheel and the - operator groups. Adding the user - joe to these - groups will allow him to use the scanner but, for obvious - security reasons, you should think twice before adding a user - to any group, especially the wheel group. - A better solution would be creating a specific group for using - the USB devices and make the scanner device accessible to - members of this group. - - So we will use, for example, a group called - usb. The - first step is the creation of this group with the help of the - &man.pw.8; command: + scanner. In the previous example, the USB scanner uses the + device node /dev/ugen0.2 which is really a + symlink to the real device node + /dev/usb/0.2.0. The symlink and the device + node are owned, respectively, by the + wheel and + operator groups. Adding the user to + these groups will allow access to the scanner. However, for + security reasons, always think twice before adding a user + to any group, especially wheel. A better + solution is to create a group to make the scanner device + accessible to members of this group. + + This example creates a group called + usb using + &man.pw.8;: &prompt.root; pw groupadd usb - Then we have to make the /dev/ugen0.2 - symlink and the /dev/usb/0.2.0 device - node accessible to the usb group - with the correct write permissions (0660 or - 0664), because by default only the owner of - these files (root) can write to them. - All of this is done by adding the following - lines to the /etc/devfs.rules - file: + Then, make the /dev/ugen0.2 symlink + and the /dev/usb/0.2.0 device node + accessible to the usb group with write + permissions of (0660 or + 0664. All of this is done by adding the + following lines to + /etc/devfs.rules: [system=5] add path ugen0.2 mode 0660 group usb add path usb/0.2.0 mode 0666 group usb - Now, one will just have to add users to the - usb group to - allow the access to the scanner: + Finally, add the users to + usb in order + to allow access to the scanner: &prompt.root; pw groupmod usb -m joe - For more details read the &man.pw.8; manual page. + For more details refer to &man.pw.8;. diff --git a/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml b/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml index e8c035e014..98d96ed097 100644 --- a/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml +++ b/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml @@ -1,5958 +1,6333 @@ Murray Stokely Reorganized by Network Servers Synopsis This chapter will cover some of the more frequently used network services on &unix; systems. We will cover how to install, configure, test, and maintain many different types of network services. Example configuration files are included throughout this chapter for you to benefit from. After reading this chapter, you will know: How to manage the inetd daemon. How to set up a network file system. How to set up a network information server for sharing user accounts. + + How to set &os; up to act as an LDAP + server or client + + + + How to set &os; up to act as an LDAP + server or client + + How to set up automatic network settings using DHCP. How to set up a domain name server. How to set up the Apache HTTP Server. How to set up a File Transfer Protocol (FTP) Server. How to set up a file and print server for &windows; clients using Samba. How to synchronize the time and date, and set up a time server, with the NTP protocol. How to configure the standard logging daemon, syslogd, to accept logs from remote hosts. Before reading this chapter, you should: Understand the basics of the /etc/rc scripts. Be familiar with basic network terminology. Know how to install additional third-party software (). Chern Lee Contributed by Updated by The &os; Documentation Project The <application>inetd</application> <quote>Super-Server</quote> Overview - &man.inetd.8; is sometimes referred to as the + The &man.inetd.8; daemon is sometimes referred to as the Internet Super-Server because it manages - connections for several services. When a connection is + connections for many 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. Settings inetd is initialized through the &man.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: inetd_enable="YES" or inetd_enable="NO" into /etc/rc.conf will enable or disable inetd starting at boot time. The command: &prompt.root; service inetd rcvar - - can be run to display the current effective setting. + can be run to display the current effective setting. Additionally, different command-line options can be passed to inetd via the inetd_flags option. Command-Line Options Like most server daemons, inetd has a number of options that it can be passed in order to modify its behaviour. See the &man.inetd.8; manual page for the full list of options. 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. Although we mention rate-limiting options below, novice users may be pleased to note that these parameters usually do - not need to be modified. These options may be useful should - you find that you are receiving an excessive amount of - connections. A full list of options can be found in the + not need to be modified. These options may be useful if + an excessive amount of connections are being established. + A full list of options can be found in the &man.inetd.8; manual. -c maximum Specify the default maximum number of simultaneous invocations of each service; the default is unlimited. May be overridden on a per-service basis with the parameter. -C rate Specify the default maximum number of times a service can be invoked from a single IP address in one minute; the default is unlimited. May be overridden on a per-service basis with the parameter. -R rate Specify the maximum number of times a service can be invoked in one minute; the default is 256. A rate of 0 allows an unlimited number of invocations. -s maximum Specify the maximum number of times a service can be invoked from a single IP address at any one time; the default is unlimited. May be overridden on a per-service basis with the parameter. <filename>inetd.conf</filename> 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: Reloading the <application>inetd</application> Configuration File &prompt.root; service inetd reload 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: service-name socket-type protocol {wait|nowait}[/max-child[/max-connections-per-ip-per-minute[/max-child-per-ip]]] user[:group][/login-class] server-program server-program-arguments An example entry for the &man.ftpd.8; daemon using IPv4 might read: ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l service-name This is the service name of the particular daemon. It must correspond to a service listed in /etc/services. This determines which port inetd must listen to. If a new service is being created, it must be placed in /etc/services first. socket-type Either stream, dgram, raw, or seqpacket. stream must be used for connection-based, TCP daemons, while dgram is used for daemons utilizing the UDP transport protocol. protocol One of the following: Protocol Explanation tcp, tcp4 TCP IPv4 udp, udp4 UDP IPv4 tcp6 TCP IPv6 udp6 UDP IPv6 tcp46 Both TCP IPv4 and v6 udp46 Both UDP IPv4 and v6 {wait|nowait}[/max-child[/max-connections-per-ip-per-minute[/max-child-per-ip]]] indicates whether the daemon invoked from inetd is able to handle its own socket or not. socket types must use the option, while stream socket daemons, which are usually multi-threaded, should use . usually hands off multiple sockets to a single daemon, while spawns a child daemon for each new socket. The maximum number of child daemons inetd may spawn can be set using the option. If a limit of ten instances of a particular daemon is needed, a /10 would be placed after . Specifying /0 allows an unlimited number of children In addition to , two other options which limit the maximum connections from a single place to a particular daemon can be enabled. limits the number of connections from any particular IP address per minutes, e.g., a value of ten would limit any particular IP address connecting to a particular service to ten attempts per minute. limits the number of children that can be started on behalf on any single IP address at any moment. These options are useful to prevent intentional or unintentional excessive resource consumption and Denial of Service (DoS) attacks to a machine. In this field, either of or is mandatory. , and are optional. A stream-type multi-threaded daemon without any , or limits would simply be: nowait. The same daemon with a maximum limit of ten daemons would read: nowait/10. The same setup with a limit of twenty connections per IP address per minute and a maximum total limit of ten child daemons would read: nowait/10/20. These options are utilized by the default settings of the &man.fingerd.8; daemon, as seen here: finger stream tcp nowait/3/10 nobody /usr/libexec/fingerd fingerd -s Finally, an example of this field with a maximum of 100 children in total, with a maximum of 5 for any one IP address would read: nowait/100/0/5. user This is the username that the particular daemon should run as. Most commonly, daemons run as the root user. For security purposes, it is common to find some servers running as the daemon user, or the least privileged nobody user. server-program The full path of the daemon to be executed when a connection is received. If the daemon is a service provided by inetd internally, then should be used. server-program-arguments This works in conjunction with by specifying the arguments, starting with argv[0], passed to the daemon on invocation. If mydaemon -d is the command line, mydaemon -d would be the value of . Again, if the daemon is an internal service, use here. Security 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 , or limitations on certain - daemons if you find that you have too many connections. + daemons if there are too many connections. By default, TCP wrapping is turned on. Consult the &man.hosts.access.5; manual page for more information on placing TCP restrictions on various inetd invoked daemons. Miscellaneous daytime, time, echo, discard, chargen, and auth are all internally provided services of inetd. The auth service provides - identity - network services, and is + identity network services, and is configurable to a certain degree, whilst the others are simply on or off. Consult the &man.inetd.8; manual page for more in-depth information. Tom Rhodes Reorganized and enhanced by Bill Swingle Written by Network File System (NFS) NFS Among the many different file systems that FreeBSD supports is the Network File System, also known as NFS. NFS allows a system to share directories and files with others over a network. By using NFS, users and programs can access files on remote systems almost as if they were local files. Some of the most notable benefits that NFS can provide are: Local workstations use less disk space because commonly used data can be stored on a single machine and still remain accessible to others over the network. There is no need for users to have separate home directories on every network machine. Home directories could be set up on the NFS server and made available throughout the network. Storage devices such as floppy disks, CDROM drives, and &iomegazip; drives can be used by other machines on the network. This may reduce the number of removable media drives throughout the network. How <acronym>NFS</acronym> Works 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: NFS server file server UNIX clients rpcbind mountd nfsd Daemon Description nfsd The NFS daemon which services requests from the NFS clients. mountd The NFS mount daemon which carries out the requests that &man.nfsd.8; passes on to it. rpcbind This daemon allows NFS clients to discover which port the NFS server is using. 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 &man.nfsiod.8; manual page for more information. Configuring <acronym>NFS</acronym> NFS configuration 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. + running can all start at boot time with a few modifications + to /etc/rc.conf. On the NFS server, make sure that the following options are configured in the /etc/rc.conf file: rpcbind_enable="YES" nfs_server_enable="YES" mountd_flags="-r" mountd runs automatically whenever the NFS server is enabled. On the client, make sure this option is present in /etc/rc.conf: nfs_client_enable="YES" 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 &man.exports.5; manual page. + be mentioned here. Other options are discussed in + the &man.exports.5; manual page. Here are a few example /etc/exports entries: NFS export examples 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, + on the 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 + the /etc/hosts file. The 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. /cdrom -ro host1 host2 host3 The following line exports /home to - three hosts by IP address. This is a useful setup if you have + three hosts by IP address. This is a useful setup on a private network without a DNS server configured. Optionally the /etc/hosts file could be configured for internal hostnames; please review &man.hosts.5; for more information. The 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. /home -alldirs 10.0.0.2 10.0.0.3 10.0.0.4 The following line exports /a so that two clients from different domains may access the file system. The 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. /a -maproot=root host.example.com box.example.org 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. + client is listed in /etc/exports. 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: # Invalid when /usr is one file system /usr/src client /usr/ports client One file system, /usr, has two lines specifying exports to the same host, client. The correct format for this situation is: /usr/src /usr/ports client 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. + are treated as a single host. This limits how file systems + may be exported; however, for most environments, this is not + an issue. The following is an example of a valid export list, where /usr and /exports are local file systems: # Export src and ports to client01 and client02, but only # client01 has root privileges on it /usr/src /usr/ports -maproot=root client01 /usr/src /usr/ports client02 # The client machines have root and can mount anywhere # on /exports. Anyone in the world can mount /exports/obj read-only /exports -alldirs -maproot=root client01 client02 /exports/obj -ro 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: &prompt.root; kill -HUP `cat /var/run/mountd.pid` or by invoking the mountd &man.rc.8; script with the appropriate parameter: &prompt.root; service mountd onereload Please refer to 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: &prompt.root; rpcbind &prompt.root; nfsd -u -t -n 4 &prompt.root; mountd -r On the NFS client: &prompt.root; nfsiod -n 4 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 + client. For testing or to temporarily + mount a remote file system execute a command like this as root on the client: NFS mounting &prompt.root; mount server:/home /mnt 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. + everything is set up correctly, the server's files should be + visible and available in the /mnt + directory. - If you want to automatically mount a remote file system + To permanently mount a remote file system each time the computer boots, add the file system to the /etc/fstab file. Here is an example: server:/home /mnt nfs rw 0 0 The &man.fstab.5; manual page lists all the available options. Locking 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): rpc_lockd_enable="YES" rpc_statd_enable="YES" Start the application by using: &prompt.root; service lockd start &prompt.root; service statd start 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 to &man.mount.nfs.8;. Refer to the &man.mount.nfs.8; manual page for further details. Practical Uses NFS has many practical uses. Some of the more common ones are listed below: NFS uses Set several machines to share a CDROM or other media among them. This is cheaper and often a more convenient method to install software on multiple machines. On large networks, it might be more convenient to configure a central NFS server in which to store all the user home directories. These home directories can then be exported to the network so that users would always have the same home directory, regardless of which workstation they log in to. Several machines could have a common - /usr/ports/distfiles directory. That - way, when you need to install a port on several machines, - you can quickly access the source without downloading it - on each machine. + /usr/ports/distfiles directory. This + allows for quick access to the source files without + downloading them on each machine. Wylie Stilwell Contributed by Chern Lee Rewritten by Automatic Mounts with <application>amd</application> amd automatic mounter daemon &man.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. Mounting an Export with <application>amd</application> - You can view the available mounts of a remote host with - the showmount command. For example, to - view the mounts of a host named foobar, you - can use: + The showmount command shows the + available mounts on a remote host. For example, to + view the mounts of a host named + foobar: &prompt.user; showmount -e foobar Exports list on foobar: /usr 10.10.10.0 /a 10.10.10.0 &prompt.user; cd /host/foobar/usr 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: amd_enable="YES" Additionally, custom flags can be passed to amd from the amd_flags option. By default, amd_flags is set to: amd_flags="-a /.amd_mnt -l syslog /host /etc/amd.map /net /etc/amd.map" 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 &man.amd.8; and &man.amd.conf.5; manual pages for more information. John Lind Contributed by Problems Integrating with Other Systems 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 on the mount from the client. If the FreeBSD system is the client, then mount the NFS file system with the option . These options may be specified using the fourth field of the fstab entry on the client for automatic mounts, or by using the parameter of the &man.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. + certain that the routers are routing the + necessary UDP information. 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 &man.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 or and may be desirable - in your application. + in the application. Examples for the FreeBSD system (freebox) as the client in /etc/fstab on freebox: fastws:/sharedfs /project nfs rw,-r=1024 0 0 As a manual mount command on freebox: &prompt.root; mount -t nfs -o -r=1024 fastws:/sharedfs /project Examples for the FreeBSD system as the server in /etc/fstab on fastws: freebox:/sharedfs /project nfs rw,-w=1024 0 0 As a manual mount command on fastws: &prompt.root; mount -t nfs -o -w=1024 freebox:/sharedfs /project 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. Bill Swingle Written by Eric Ogren Enhanced by Udo Erdelhoff Network Information System (NIS/YP) What Is It? NIS Solaris HP-UX AIX Linux NetBSD OpenBSD 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. yellow pages 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. NIS domains 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. Windows NT It is similar to the &windowsnt; domain system; although the internal implementation of the two are not at all similar, the basic functionality can be compared. - Terms/Processes You Should Know + <acronym>NIS</acronym>Terms and Processes - 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 several terms and important user + processes that will be explained while attempting to + implement NIS on FreeBSD, regardless if the system is a + NIS server or a NIS client: rpcbind portmap Term Description NIS domainname An NIS master server and all of its clients (including its slave servers) have a NIS domainname. Similar to an &windowsnt; domain name, the NIS domainname does not have anything to do with DNS. rpcbind Must be running in order to enable RPC (Remote Procedure Call, a network protocol used by NIS). If rpcbind is not running, it will be impossible to run an NIS server, or to act as an NIS client. ypbind Binds an NIS client to its NIS server. It will take the NIS domainname from the system, and using RPC, connect to the server. ypbind is the core of client-server communication in an NIS environment; if ypbind dies on a client machine, it will not be able to access the NIS server. ypserv Should only be running on NIS servers; this is the NIS server process itself. If &man.ypserv.8; dies, then the server will no longer be able to respond to NIS requests (hopefully, there is a slave server to take over for it). There are some implementations of NIS (but not the FreeBSD one), that do not try to reconnect to another server if the server it used before dies. Often, the only thing that helps in this case is to restart the server process (or even the whole server) or the ypbind process on the client. rpc.yppasswdd Another process that should only be running on NIS master servers; this is a daemon that will allow NIS clients to change their NIS passwords. If this daemon is not running, users will have to login to the NIS master server and change their passwords there. How Does It Work? 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. Machine Types NIS master server A NIS master server. This server, analogous to a &windowsnt; primary domain controller, maintains the files used by all of the NIS clients. The passwd, group, and other various files used by the NIS clients live on the master server. It is possible for one machine to be an NIS master server for more than one NIS domain. However, this will not be covered in this introduction, which assumes a relatively small-scale NIS environment. NIS slave server NIS slave servers. Similar to the &windowsnt; backup domain controllers, NIS slave servers maintain copies of the NIS master's data files. NIS slave servers provide the redundancy, which is needed in important environments. They also help to balance the load of the master server: NIS Clients always attach to the NIS server whose response they get first, and this includes slave-server-replies. NIS client NIS clients. NIS clients, like most &windowsnt; workstations, authenticate against the NIS server (or the &windowsnt; domain controller in the &windowsnt; workstations case) to log on. Using NIS/YP This section will deal with setting up a sample NIS environment. Planning - Let us assume that you are the administrator of a small - university lab. This lab, which consists of 15 FreeBSD + Let us assume that an administrator of a small + university lab, which consists of 15 FreeBSD machines, currently has no centralized point of - administration; each machine has its own + 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 you add a user to the lab, you - must run adduser on all 15 machines. - Clearly, this has to change, so you have decided to convert - the lab to use NIS, using two of the machines as - servers. + intervention; currently, a user is added to the lab, the + process must be ran on all 15 machines. + The lab would clearly benefit from the addition of two + NIS servers. Therefore, the configuration of the lab now looks something like: Machine name IP address Machine role ellington 10.0.0.2 NIS master coltrane 10.0.0.3 NIS slave basie 10.0.0.4 Faculty workstation bird 10.0.0.5 Client machine cli[1-11] 10.0.0.[6-17] Other client machines - If you are setting up a NIS scheme for the first time, - it is a good idea to think through how you want to go about - it. No matter what the size of your network, there are a - few decisions that need to be made. + If this is the first time a 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. Choosing a NIS Domain Name NIS domainname - This might not be the domainname that - you are used to. It is more accurately called the + This might not be the normal domainname + for the network. It is more accurately called the NIS domainname. When a client broadcasts its requests for info, it includes the name of the NIS domain that it is part of. This is how multiple servers on one network can tell which server should answer which request. Think of the NIS domainname as the name for a group of hosts that are related in some way. Some organizations choose to use their Internet domainname for their NIS domainname. This is not recommended as it can cause confusion when trying to debug network problems. The NIS domainname should be unique - within your network and it is helpful if it describes the + within the network and it is helpful if it describes the group of machines it represents. For example, the Art department at Acme Inc. might be in the acme-art NIS domain. For this example, - assume you have chosen the name + assume the chosen name will be test-domain. SunOS However, some operating systems (notably &sunos;) use their NIS domain name as their Internet domain name. If - one or more machines on your network have this - restriction, you must use the - Internet domain name as your NIS domain name. + one or more machines on the network have this + restriction, it must be used as the + Internet domain name for the NIS domain name. Physical Server Requirements There are several things to keep in mind when choosing a machine to use as a NIS server. One of the unfortunate things about NIS is the level of dependency the clients have on the server. If a client cannot contact the server for its NIS domain, very often the machine becomes unusable. The lack of user and group information causes most systems to temporarily freeze up. With this in mind - you should make sure to choose a machine that will not be - prone to being rebooted regularly, or one that might be + be sure to choose a machine that will not be + prone to being rebooted frequently, or one that might be used for development. The NIS server should ideally be a stand alone machine whose sole purpose in life is to be an - NIS server. If you have a network that is not very + NIS server. If the network is not very heavily used, it is acceptable to put the NIS server on a - machine running other services, just keep in mind that if - the NIS server becomes unavailable, it will affect - all of your NIS clients - adversely. + machine running other services, however; if + the NIS server becomes unavailable, it will adversely affect + all NIS clients. NIS Servers The canonical copies of all NIS information are stored on a single machine called the NIS 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 being served. A single NIS server can support several domains at once, therefore it is possible to have several such directories, one for each supported domain. Each domain will have its own independent set of maps. NIS master and slave servers handle all NIS requests with the ypserv daemon. ypserv 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 NIS Master Server NIS server configuration Setting up a master NIS server can be relatively - straight forward, depending on your needs. FreeBSD comes - with support for NIS out-of-the-box. All you need is to - add the following lines to - /etc/rc.conf, and FreeBSD will do the - rest for you. + straight forward, depending on environmental needs. &os; + comes with support for NIS out-of-the-box. It only needs to + be enabled by adding the following lines to + /etc/rc.conf: nisdomainname="test-domain" This line will set the NIS domainname to test-domain upon network setup (e.g., after reboot). nis_server_enable="YES" This will tell FreeBSD to start up the NIS server processes when the networking is next brought up. nis_yppasswdd_enable="YES" This will enable the rpc.yppasswdd daemon which, as mentioned above, will allow users to change their NIS password from a client machine. - Depending on your NIS setup, you may need to add - further entries. See the Depending on the NIS setup, additional entries may + be required. See the section about NIS servers that are also NIS clients, below, for details. After setting up the above entries, run the command /etc/netstart as superuser. It will - set up everything for you, using the values you defined in + set up everything, using the values defined in /etc/rc.conf. As a last step, before initializing the NIS maps, start the ypserv daemon manually: &prompt.root; service ypserv start Initializing the NIS Maps NIS maps The NIS maps are database files, that are kept in the /var/yp directory. They are generated from configuration files in the /etc directory of the NIS master, - with one exception: the - /etc/master.passwd file. This is for - a good reason, you do not want to propagate passwords to - your root and other administrative + with one exception: /etc/master.passwd. + This is for + a good reason, never propagate passwords for + root and other administrative accounts to all the servers in the NIS domain. Therefore, - before we initialize the NIS maps, you should: + before the the NIS maps are initialized, configure the primary + password files: &prompt.root; cp /etc/master.passwd /var/yp/master.passwd &prompt.root; cd /var/yp &prompt.root; vi master.passwd - You should remove all entries regarding system + It is advisable to remove all entries regarding system accounts (bin, tty, kmem, games, etc), as well as any accounts - that you do not want to be propagated to the NIS clients + that do not need to be propagated to the NIS clients (for example root and any other UID 0 (superuser) accounts). - Make sure the + Ensure the /var/yp/master.passwd is neither - group nor world readable (mode 600)! Use the - chmod command, if + group or world readable (mode 600)! Use the + chmod command, as appropriate. Tru64 UNIX - When you have finished, it is time to initialize the - NIS maps! FreeBSD includes a script named - ypinit to do this for you (see its + When this task has been completed, it is time to + initialize the NIS maps. FreeBSD includes a script named + ypinit to do this (see its manual page for more information). Note that this script is available on most &unix; Operating Systems, but not on all. On Digital UNIX/Compaq Tru64 UNIX it is called ypsetup. Because we are generating maps for an NIS master, we are going to pass the option to ypinit. - To generate the NIS maps, assuming you already performed - the steps above, run: + To generate the NIS maps run: ellington&prompt.root; ypinit -m test-domain Server Type: MASTER Domain: test-domain Creating an YP server will require that you answer a few questions. Questions will all be asked at the beginning of the procedure. Do you want this procedure to quit on non-fatal errors? [y/n: n] n Ok, please remember to go back and redo manually whatever fails. If you don't, something might not work. At this point, we have to construct a list of this domains YP servers. rod.darktech.org is already known as master server. Please continue to add any slave servers, one per line. When you are done with the list, type a <control D>. master server : ellington next host to add: coltrane next host to add: ^D The current list of NIS servers looks like this: ellington coltrane Is this correct? [y/n: y] y [..output from map generation..] NIS Map update completed. ellington has been setup as an YP master server without any errors. - ypinit should have created - /var/yp/Makefile from + At this point, ypinit should have + created /var/yp/Makefile from /var/yp/Makefile.dist. - When created, this file assumes that you are operating - in a single server NIS environment with only FreeBSD + When created, this file assumes that the operating + environment is a single server NIS system with only &os; machines. Since test-domain has - a slave server as well, you must edit - /var/yp/Makefile: + a slave server as well, edit + /var/yp/Makefile as well: ellington&prompt.root; vi /var/yp/Makefile You should comment out the line that says NOPUSH = "True" (if it is not commented out already). Setting up a NIS Slave Server NIS slave server Setting up an NIS slave server is even more simple than setting up the master. Log on to the slave server and edit the file /etc/rc.conf as you did before. The only difference is that we now must use the option when running ypinit. The option requires the name of the NIS master be passed to it as well, so our command line looks like: coltrane&prompt.root; ypinit -s ellington test-domain Server Type: SLAVE Domain: test-domain Master: ellington Creating an YP server will require that you answer a few questions. Questions will all be asked at the beginning of the procedure. Do you want this procedure to quit on non-fatal errors? [y/n: n] n Ok, please remember to go back and redo manually whatever fails. If you don't, something might not work. There will be no further questions. The remainder of the procedure should take a few minutes, to copy the databases from ellington. Transferring netgroup... ypxfr: Exiting: Map successfully transferred Transferring netgroup.byuser... ypxfr: Exiting: Map successfully transferred Transferring netgroup.byhost... ypxfr: Exiting: Map successfully transferred Transferring master.passwd.byuid... ypxfr: Exiting: Map successfully transferred Transferring passwd.byuid... ypxfr: Exiting: Map successfully transferred Transferring passwd.byname... ypxfr: Exiting: Map successfully transferred Transferring group.bygid... ypxfr: Exiting: Map successfully transferred Transferring group.byname... ypxfr: Exiting: Map successfully transferred Transferring services.byname... ypxfr: Exiting: Map successfully transferred Transferring rpc.bynumber... ypxfr: Exiting: Map successfully transferred Transferring rpc.byname... ypxfr: Exiting: Map successfully transferred Transferring protocols.byname... ypxfr: Exiting: Map successfully transferred Transferring master.passwd.byname... ypxfr: Exiting: Map successfully transferred Transferring networks.byname... ypxfr: Exiting: Map successfully transferred Transferring networks.byaddr... ypxfr: Exiting: Map successfully transferred Transferring netid.byname... ypxfr: Exiting: Map successfully transferred Transferring hosts.byaddr... ypxfr: Exiting: Map successfully transferred Transferring protocols.bynumber... ypxfr: Exiting: Map successfully transferred Transferring ypservers... ypxfr: Exiting: Map successfully transferred Transferring hosts.byname... ypxfr: Exiting: Map successfully transferred coltrane has been setup as an YP slave server without any errors. Don't forget to update map ypservers on ellington. - You should now have a directory called + There should be a directory called /var/yp/test-domain. Copies of the - NIS master server's maps should be in this directory. You - will need to make sure that these stay updated. The + NIS master server's maps should be in this directory. These + files must always be up to date. The following /etc/crontab entries on - your slave servers should do the job: + the slave servers should do the job: 20 * * * * root /usr/libexec/ypxfr passwd.byname 21 * * * * root /usr/libexec/ypxfr passwd.byuid These two lines force the slave to sync its 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, due to + to push any map changes to its slaves; however, due to the importance of correct password information on other clients depending on the slave server, it is recommended to specifically force the password map updates frequently. This is especially important on busy networks where map updates might not always complete. Now, run the command /etc/netstart on the slave server as well, which again starts the NIS server. NIS Clients - An NIS client establishes what is called a binding to a + An NIS client establishes what is called a binding to a particular NIS server using the - ypbind daemon. - ypbind checks the system's default + ypbind daemon. The + ypbind command checks the system's default domain (as set by the domainname command), and begins broadcasting RPC requests on the local network. These requests specify the name of the domain for which ypbind is attempting to establish a binding. If a server that has been configured to serve the requested domain receives one of the broadcasts, it will respond to ypbind, which will record the server's address. If there are several servers available (a master and several slaves, for example), ypbind will use the address of the first one to respond. From that point on, the client system will direct all of its NIS requests to that server. ypbind will occasionally ping the server to make sure it is still up and running. If it fails to receive a reply to one of its pings within a reasonable amount of time, ypbind will mark the domain as unbound and begin broadcasting again in the hopes of locating another server. Setting Up a NIS Client NIS client configuration Setting up a FreeBSD machine to be a NIS client is fairly straightforward. - Edit the file /etc/rc.conf + Edit /etc/rc.conf and add the following lines in order to set the NIS - domainname and start ypbind upon + domainname and start ypbind during network startup: nisdomainname="test-domain" nis_client_enable="YES" To import all possible password entries from the - NIS server, remove all user accounts from your + NIS server, remove all user accounts from the /etc/master.passwd file and use vipw to add the following line to the end of the file: +::::::::: This line will afford anyone with a valid account in the NIS server's password maps an - account. There are many ways to configure your NIS + account. There are many ways to configure the NIS client by changing this line. See the netgroups section below for more information. For more detailed reading see O'Reilly's book on Managing NFS and NIS. - You should keep at least one local account (i.e. - not imported via NIS) in your + Keep in mind that at least one local account (i.e. + not imported via NIS) must exist in /etc/master.passwd and this account should also be a member of the group wheel. If there is something wrong with NIS, this account can be used to log in remotely, become root, and fix things. To import all possible group entries from the NIS - server, add this line to your - /etc/group file: + server, add this line to + /etc/group: +:*:: To start the NIS client immediately, execute the following commands as the superuser: &prompt.root; /etc/netstart &prompt.root; service ypbind start - After completing these steps, you should be able to - run ypcat passwd and see the NIS + After completing these steps, the command, + ypcat passwd, should show the server's passwd map. - + + NIS Security - In general, any remote user can issue an RPC to - &man.ypserv.8; and retrieve the contents of your NIS maps, - provided the remote user knows your domainname. To prevent + In general, any remote user may issue an RPC to + &man.ypserv.8; and retrieve the contents of the NIS maps, + provided the remote user knows the domainname. To prevent such unauthorized transactions, &man.ypserv.8; supports a feature called securenets which can be used to restrict access to a given set of hosts. At startup, &man.ypserv.8; will attempt to load the securenets information from a file called /var/yp/securenets. This path varies depending on the path specified with the option. 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 file might look like this: # allow connections from local host -- mandatory 127.0.0.1 255.255.255.255 # allow connections from any host # on the 192.168.128.0 network 192.168.128.0 255.255.255.0 # allow connections from any host # between 10.0.0.0 to 10.0.15.255 # this includes the machines in the testlab 10.0.0.0 255.255.240.0 If &man.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. While both of these access control mechanisms provide some security, they, like the privileged port test, are vulnerable to IP spoofing attacks. All - NIS-related traffic should be blocked at your + NIS-related traffic should be blocked at the firewall. Servers using /var/yp/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 and/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 the client systems in question or the abandonment of /var/yp/securenets. Using /var/yp/securenets on a server with such an archaic implementation of TCP/IP is a really bad idea and will lead to loss of NIS functionality - for large parts of your network. + for large parts of the network. TCP Wrappers - The use of the TCP Wrapper - package increases the latency of your NIS server. The + 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 or with slow - NIS servers. If one or more of your client systems - suffers from these symptoms, you should convert the client + NIS servers. If one or more of the client systems + suffers from these symptoms, convert the client systems in question into NIS slave servers and force them to bind to themselves. Barring Some Users from Logging On 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 + this, add -username with the correct number of colons like other entries 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. + the username of the user to bar from logging in. The line with the blocked user must be before the + line for allowing NIS users. This should preferably be done using vipw, - since vipw will sanity check your changes + since vipw will sanity check the 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 + automatically rebuild the password database after + editing. For example, to bar user bill from logging on to - basie we would: + basie: basie&prompt.root; vipw [add -bill::::::::: to the end, exit] vipw: rebuilding the database... vipw: done basie&prompt.root; cat /etc/master.passwd root:[password]:0:0::0:0:The super-user:/root:/bin/csh toor:[password]:0:0::0:0:The other super-user:/root:/bin/sh daemon:*:1:1::0:0:Owner of many system processes:/root:/sbin/nologin operator:*:2:5::0:0:System &:/:/sbin/nologin bin:*:3:7::0:0:Binaries Commands and Source,,,:/:/sbin/nologin tty:*:4:65533::0:0:Tty Sandbox:/:/sbin/nologin kmem:*:5:65533::0:0:KMem Sandbox:/:/sbin/nologin games:*:7:13::0:0:Games pseudo-user:/usr/games:/sbin/nologin news:*:8:8::0:0:News Subsystem:/:/sbin/nologin man:*:9:9::0:0:Mister Man Pages:/usr/share/man:/sbin/nologin bind:*:53:53::0:0:Bind Sandbox:/:/sbin/nologin uucp:*:66:66::0:0:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico xten:*:67:67::0:0:X-10 daemon:/usr/local/xten:/sbin/nologin pop:*:68:6::0:0:Post Office Owner:/nonexistent:/sbin/nologin nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/sbin/nologin -bill::::::::: +::::::::: basie&prompt.root; Udo Erdelhoff Contributed by Using Netgroups netgroups 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 + well for special rules in an environment with small numbers of + users and/or machines. On larger networks, administrators + will likely forget to bar some users from + logging onto sensitive machines, or 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. + Good Thing in 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 + Let us assume that the successful introduction of NIS in + the laboratory caught a superiors' interest. The next + task is to extend the 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. User Name(s) Description alpha, beta Normal employees of the IT department charlie, delta The new apprentices of the IT department echo, foxtrott, golf, ... Ordinary employees able, baker, ... The current interns Machine Name(s) Description war, death, famine, pollution - Your most important servers. Only the IT + The most important servers deployed. Only the IT employees are allowed to log onto these machines. pride, greed, envy, wrath, lust, sloth Less important servers. All members of the IT department are allowed to login onto these machines. one, two, three, four, ... Ordinary workstations. Only the real employees are allowed to use these machines. trashcan A very old machine without any critical data. Even the intern is allowed to use this box. - If you tried to implement these restrictions by separately - blocking each user, you would have to add one + An attempt to implement these restrictions by separately + blocking each user, would require the addition of the -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. + each system's passwd. One line for each user + who is not allowed to login onto that system. Forgetting just one + entry could cause significant trouble. It may be feasible to + do this correctly during the initial setup; however, eventually + someone will forget to add these lines + for new users. 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 + advantages. Each user need not be handled separately; they + would be assigned to one or more netgroups and logins would + be allowed or forbidden for all members of the netgroup. + While adding a new + machine, login restrictions must be defined for all + netgroups. If a new user is added, they must be added + 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. + of user and machine do... 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 map - netgroup. FreeBSD's &man.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 + netgroup. &os;'s &man.ypinit.8; does not create this map + by default, but its NIS implementation will support it + after creation. To create an empty map, simply type ellington&prompt.root; vi /var/yp/netgroup - and start adding content. For our example, we need at + and begin adding content. For our example, we need at least four netgroups: IT employees, IT apprentices, normal employees and interns. IT_EMP (,alpha,test-domain) (,beta,test-domain) IT_APP (,charlie,test-domain) (,delta,test-domain) USERS (,echo,test-domain) (,foxtrott,test-domain) \ (,golf,test-domain) INTERNS (,able,test-domain) (,baker,test-domain) 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: The name of the host(s) where the following items are - valid. If you do not specify a hostname, the entry is - valid on all hosts. If you do specify a hostname, you - will enter a realm of darkness, horror and utter - confusion. + valid. If a hostname is not specified, the entry is + valid on all hosts. If a hostname is specified, it + will need to be micro-managed within this + configuration. The name of the account that belongs to this netgroup. - The NIS domain for the account. You can import - accounts from other NIS domains into your netgroup if you - are one of the unlucky fellows with more than one NIS - domain. + The NIS domain for the account. Accounts may be + imported from other NIS domains into a netgroup. - Each of these fields can contain wildcards. See + Each of these fields may contain wildcards. See &man.netgroup.5; for details. netgroups Netgroup names longer than 8 characters should not be - used, especially if you have machines running other - operating systems within your NIS domain. The names are - case sensitive; using capital letters for your netgroup + used, especially with machines running other + operating systems within the NIS domain. The names are + case sensitive; using capital letters for netgroup names is an easy way to distinguish between user, machine and netgroup names. - Some NIS clients (other than FreeBSD) cannot handle + Some NIS clients (other than &os;) cannot handle netgroups with a large number of entries. For example, some older versions of &sunos; start to cause trouble if a netgroup contains more than 15 entries. - You can circumvent this limit by creating several - sub-netgroups with 15 users or less and a real netgroup that - consists of the sub-netgroups: + This limit may be circumvented by creating several + sub-netgroups with 15 users or fewer and a real netgroup + consisting of the sub-netgroups: BIGGRP1 (,joe1,domain) (,joe2,domain) (,joe3,domain) [...] BIGGRP2 (,joe16,domain) (,joe17,domain) [...] BIGGRP3 (,joe31,domain) (,joe32,domain) BIGGROUP BIGGRP1 BIGGRP2 BIGGRP3 - You can repeat this process if you need more than 225 - users within a single netgroup. + Repeat this process if more than 225 + users will exist within a single netgroup. - Activating and distributing your new NIS map is + Activating and distributing the new NIS map is easy: ellington&prompt.root; cd /var/yp ellington&prompt.root; make This will generate the three NIS maps netgroup, netgroup.byhost and netgroup.byuser. Use &man.ypcat.1; to - check if your new NIS maps are available: + check if the new NIS maps are available: ellington&prompt.user; ypcat -k netgroup ellington&prompt.user; ypcat -k netgroup.byhost ellington&prompt.user; ypcat -k netgroup.byuser 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 + command will not produce output without specified + host-specific netgroups. The third command may 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 - &man.vipw.8; and replace the line + war, use + &man.vipw.8; to replace the line +::::::::: with +@IT_EMP::::::::: 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 + this, import all user entries + without allowing them to login into the 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 + entries. It is possible to replace any field in the passwd entry by placing a default value in - your /etc/master.passwd. + /etc/master.passwd. Make sure that the line +:::::::::/sbin/nologin is placed after +@IT_EMP:::::::::. Otherwise, all user accounts imported from NIS will have /sbin/nologin as their login shell. - 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 + After this change, the NIS map will only need modification + when a new employee joins the IT department. A similar approach + for the less important servers may be used by replacing the old +::::::::: in their local version of /etc/master.passwd with something like this: +@IT_EMP::::::::: +@IT_APP::::::::: +:::::::::/sbin/nologin The corresponding lines for the normal workstations could be: +@IT_EMP::::::::: +@USERS::::::::: +:::::::::/sbin/nologin 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 + apprentices are allowed to login onto the main servers. + Add a new netgroup IT_INTERN, then 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 + 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 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 + entries for the NIS map netgroup should look like this: BIGSRV IT_EMP IT_APP SMALLSRV IT_EMP IT_APP ITINTERN USERBOX IT_EMP ITINTERN USERS 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. + 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 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: +@BOXNAME::::::::: +:::::::::/sbin/nologin - Once you have completed this task for all your machines, - you will not have to modify the local versions of + 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 with some additional goodies: # Define groups of users first IT_EMP (,alpha,test-domain) (,beta,test-domain) IT_APP (,charlie,test-domain) (,delta,test-domain) DEPT1 (,echo,test-domain) (,foxtrott,test-domain) DEPT2 (,golf,test-domain) (,hotel,test-domain) DEPT3 (,india,test-domain) (,juliet,test-domain) ITINTERN (,kilo,test-domain) (,lima,test-domain) D_INTERNS (,able,test-domain) (,baker,test-domain) # # Now, define some groups based on roles USERS DEPT1 DEPT2 DEPT3 BIGSRV IT_EMP IT_APP SMALLSRV IT_EMP IT_APP ITINTERN USERBOX IT_EMP ITINTERN USERS # # And a groups for a special tasks # Allow echo and golf to access our anti-virus-machine SECURITY IT_EMP (,echo,test-domain) (,golf,test-domain) # # machine-based netgroups # Our main servers WAR BIGSRV FAMINE BIGSRV # User india needs access to this server POLLUTION BIGSRV (,india,test-domain) # # This one is really important and needs more access restrictions DEATH IT_EMP # # The anti-virus-machine mentioned above ONE SECURITY # # Restrict a machine to a single user TWO (,hotel,test-domain) # [...more groups to follow] - 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 + If some kind of database is used to manage the user + accounts, it may be possible to create the first part of the + map using the database's reporting 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 + to use machine-based netgroups. When 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. + labs, role-based netgroups instead of + machine-based netgroups may be used to keep the size of the NIS + map within reasonable limits. Important Things to Remember - There are still a couple of things that you will need to - do differently now that you are in an NIS environment. + There are still a couple of things administrators need to + do differently now that machines are in an NIS + environment. - Every time you wish to add a user to the lab, you - must add it to the master NIS server - only, and you must remember - to rebuild the NIS maps. If you forget to do - this, the new user will not be able to login anywhere - except on the NIS master. For example, if we needed to - add a new user jsmith to the lab, we - would: + Every time a new user is added to the lab, they + must be added to the master NIS server + and the NIS maps will need rebuilt. If + this step is omitted, the new user will not be able to login + anywhere except on the NIS master. For example, if we + needed to add a new user jsmith to + the lab, we would: &prompt.root; pw useradd jsmith &prompt.root; cd /var/yp &prompt.root; make test-domain - You could also run adduser jsmith + The user may also be added using + adduser jsmith instead of pw useradd jsmith. Keep the administration accounts out of the - NIS maps. You do not want to be propagating - administrative accounts and passwords to machines that - will have users that should not have access to those - accounts. + NIS maps. This is undesirable as it will + create a security risk. These users and passwords should + not be propagated to all machines. Especially if these + machines will have users whom should not have access to + those accounts. Keep the NIS master and slave secure, and minimize their downtime. If somebody either hacks or simply turns off these machines, they have effectively rendered many people without the ability to login to the lab. This is the chief weakness of any centralized - administration system. If you do not protect your NIS - servers, you will have a lot of angry users! + administration system. If the NIS servers are not + protected, there will be a lot of angry users and + unhappy management! NIS v1 Compatibility - FreeBSD's ypserv has some - support for serving NIS v1 clients. FreeBSD's NIS - implementation only uses the NIS v2 protocol, however other + &os;'s ypserv has some + support for serving NIS v1 clients. &os;'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 + systems will attempt 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 + transfer requests. Additionally, 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. NIS Servers That Are Also NIS Clients - Care must be taken when running + 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 + A host may be forced to bind to a particular server by running ypbind with the - 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: + flag. Add the following lines to + /etc/rc.conf to enable this feature + during every system boot: nis_client_enable="YES" # run client stuff as well nis_client_flags="-S NIS domain,server" See &man.ypbind.8; for further information. Password Formats NIS password formats 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. + the NIS server is using DES encrypted passwords, it will only + support clients that are also using DES. For example, if any + &solaris; NIS clients exist on the network, there is a highly + likelihood DES must be used for encrypted passwords. - To check which format your servers and clients are using, + To check which format the 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: default:\ :passwd_format=des:\ :copyright=/etc/COPYRIGHT:\ [Further entries elided] 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 + If any changes were made to + /etc/login.conf, the + login capability database must be rebuilt by running the following command as root: &prompt.root; cap_mkdb /etc/login.conf The format of passwords already in /etc/master.passwd will not be updated until a user changes his password for the first time after the login capability database is rebuilt. Next, in order to ensure that passwords are encrypted with - the format that you have chosen, you should also check that + the chosen format, 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 + /etc/auth.conf gives precedence to the + chosen password format. To do this, place the chosen format + first in the list. For example, when using DES encrypted passwords, the entry would be: crypt_default = des blf md5 Having followed the above steps on each of the &os; based - NIS servers and clients, you can be sure that they all agree - on which password format is used within your network. If you + NIS servers and clients, verify that they all agree + on which password format is used within the network. If users 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 heterogeneous - network, you will probably have to use DES on all systems + to deploy an NIS server for a heterogeneous + network, they will probably have to use DES on all systems because it is the lowest common standard. + + + + + Tom + Rhodes + Written by + + + + &os; and <acronym>LDAP</acronym> + + LDAP + + LDAP, the Lightweight Directory Access + Protocol, is an application layer protocol used to access, + modify, and authenticate (bind) using a distributed directory + information service. Think of it as a phone or record book which + stores several levels of hierarchical, homogeneous information. + It is often used in networks where users often need access to + several levels of internal information utilizing a single + account. For example, email authentication, pulling employee + contact information, and internal website authentication might + all make use of a single user in the LDAP + server's record base. + + This section will not provide a history or the implementation + details of the protocol. These sections were authored to get an + LDAP server and/or client configured both + quickly and securely; however, any information base requires + planning and this is no exception. + + Planning should include what type of information will be + stored, what that information will be used for, whom should + have access to said information, and how to secure this + information from prying eyes. + + + <acronym>LDAP</acronym> Terminology and Structure + + Before continuing, several parts of LDAP + must be explained to prevent confusion. And confusion with + this configuration is relatively simple. To begin, all + directory entries consist of a group of + attributes. Each of these attribute sets + contain a name, a unique identifier known as a + DN or distinguished name normally built from + several other attributes such as the RDN. + The RDN or relative distinguished name, is + a more common name for the attribute. Like directories have + absolute and relative paths, consider a DN + as an absolute path and the RDN as the + relative path. + + As an example, an entry might look like the + following: + + &prompt.user; ldapsearch -xb "uid=trhodes,ou=users,o=example.com" + + # extended LDIF +# +# LDAPv3 +# base <uid=trhodes,ou=users,o=example.com> with scope subtree +# filter: (objectclass=*) +# requesting: ALL +# + +# trhodes, users, example.com +dn: uid=trhodes,ou=users,o=example.com +mail: trhodes@example.com +cn: Tom Rhodes +uid: trhodes +telephoneNumber: (xxx) xxx-xxxx + +# search result +search: 2 +result: 0 Success + +# numResponses: 2 +# numEntries: 1 + + In this example, it is very obvious what the various + attributes are; however, the cn attribute + should be noticed. This is the RDN discussed + previously. In addition, there is a unique user id provided + here. It is common practice to have specific uid or uuids for + entries to ease in any future migration. + + + + Configuring an <acronym>LDAP</acronym> Server + + LDAP Server + + To configure &os; to act as an LDAP + server, the OpenLDAP port needs installed. This may be + accomplished using the pkg_add command + or by installing the + net/openldap24-server + port. Building the port is recommended as the administrator + may select a great deal of options at this time and disable + some options. In most cases, the defaults will be fine; + however, this is the time to enable SQL support if + needed. + + A few directories will be required from this point on, + at minimal, a data directory and a directory to store the + certificates in. Create them both with the following + commands: + + &prompt.root; mkdir /var/db/openldap-data + + &prompt.root; mkdir /usr/local/etc/openldap/private + + Copy over the database configuration file: + + &prompt.root; cp /usr/local/etc/openldap/DB_CONFIG.example /var/db/openldap-data/DB_CONFIG + + The next phase is to configure the SSL + certificates. While creating certificates is discussed in + the OpenSSL section in this + book, a certificate authority is needed so a different method + will be used. It is recommended that this section be reviewed + prior to configuring to ensure correct information is entered + during the certificate creation process below. + + The following commands must be executed in the + + /usr/local/etc/openldap/private directory. This + is important as the file permissions will need to be restrictive + and users should not have access to these files directly. To + create the certificates, issues the following commands. + + &prompt.root; openssl req -days 365 -nodes -new -x509 -keyout ca.key -out ../ca.crt + + The entries for these may be completely generic + except for the + Common Name entry. This entry must have + something different than the system hostname. If the entry + is the hostname, it would be like the hostname is attempting + to verify hostname. In cases with a self signed certificate + like this example, just prefix the hostname with + CA for certificate authority. + + The next task is to create a certificate signing request + and a private key. To do this, issue the following + commands: + + &prompt.root; openssl req -days 365 -nodes -new -keyout server.key -out server.csr + + During the certificate generation process, be sure to + correctly set the common name attribute. After this has + been completed, the key will need signed: + + &prompt.root; openssl x509 -req -days 365 -in server.csr -out ../server.crt -CA ../ca.crt -CAkey ca.key -CAcreateserial + + The final part of the certificate generation process + is to generate and sign the client certificates: + + &prompt.root; openssl req -days 365 -nodes -new -keyout client.key -out client.csr + + &prompt.root; openssl x509 -req -days 3650 -in client.csr -out ../client.crt -CA ../ca.crt -CAkey ca.key + + Remember, again, to respect the common name attribute. This + is a common cause for confusion during the first attempt to + configure LDAP. In addition, ensure that + a total of eight (8) new files have been generated through + the proceeding commands. If so, the next step is to edit + /usr/local/etc/openldap/slapd.conf and add + the following options: + + TLSCipherSuite HIGH:MEDIUM:+SSLv3 +TLSCertificateFile /usr/local/etc/openldap/server.crt +TLSCertificateKeyFile /usr/local/etc/openldap/private/server.key +TLSCACertificateFile /usr/local/etc/openldap/ca.crt + + In addition, edit + /usr/local/etc/openldap/ldap.conf and + add the following lines: + + TLS_CACERT /usr/local/etc/openldap/ca.crt +TLS_CIPHER_SUITE HIGH:MEDIUM:+SSLv3 + + While editing these this file, set the + to the desired values, and uncomment all three of the + , and + options. In addition, set the + to contain + and . + + The resulting file should look similar to the following + shown here: + + BASE dc=example,dc=com +URI ldap:// ldaps:// + +SIZELIMIT 12 +TIMELIMIT 15 +#DEREF never + +TLS_CACERT /usr/local/etc/openldap/ca.crt +TLS_CIPHER_SUITE HIGH:MEDIUM:+SSLv3 + + A password for the server will need to be created as the + default is extremely poor as is normal in this industry. To + do this, issue the following command, sending the output to + slapd.conf: + + &prompt.root; slappasswd -h "{SHA}" >> /usr/local/etc/openldap/slapd.conf + + There will be a prompt for entering the password and, + if the process does not fail, a password hash will be added + to the end of slapd.conf. The + slappasswd understands several hashing + formats, refer to the manual page for more information. + + Edit /usr/local/etc/openldap/slapd.conf + and add the following lines: + + password-hash {sha} +allow bind_v2 + + In addition, the in this file must + be updated to match the from the previous + configuration. The option should + also be set. A good recommendation is something like + . Before saving this file, place + the option in front of the password + output from the slappasswd and delete the + old option above. The end result + should look similar to this: + + TLSCipherSuite HIGH:MEDIUM:+SSLv3 +TLSCertificateFile /usr/local/etc/openldap/server.crt +TLSCertificateKeyFile /usr/local/etc/openldap/private/server.key +TLSCACertificateFile /usr/local/etc/openldap/ca.crt +rootpw {SHA}W6ph5Mm5Pz8GgiULbPgzG37mj9g= + + Finally, enable the OpenLDAP + service in rc.conf. At this time, + setting up a URI and providing the group + and user to run as may be useful. + Edit /etc/rc.conf and add the following + lines: + + slapd_enable="YES" +slapd_flags="-4 -h ldaps:///" + + At this point the server should be ready to be brought + up and tested. To perform this task, issue the following + command: + + &prompt.root; service slapd start + + If everything was configured correctly, a search of the + directory should show a successful connection with a single + response as in this example: + + &prompt.root; ldapsearch -Z + + # extended LDIF +# +# LDAPv3 +# base <dc=example,dc=com> (default) with scope subtree +# filter: (objectclass=*) +# requesting: ALL +# + +# search result +search: 3 +result: 32 No such object + +# numResponses: 1 + + Considering the service should now be responding, as it + is above, the directory may be populated using the + ldapadd command. In this example, there + is a file containing a list of users to be added to this + particular directory. First, create a file to be imported + with the following dataset: + + dn: dc=example,dc=com +objectclass: dcObject +objectclass: organization +o: Example +dc: Example + +dn: cn=Manager,dc=example,dc=com +objectclass: organizationalRole +cn: Manager + + + To debug any of the following, stop the + slapd service using the + service command and start it using with + debugging options. To accomplish this, issue the following + command: + + &prompt.root; /usr/local/libexec/slapd -d -1 + + + To import this datafile, issue the following command, + assuming the file is import.ldif: + + &prompt.root; ldapadd -Z -D "cn=Manager,dc=example,dc=com" -W -f import.ldif + + There will be a request for the password specified earlier, + and the output should look like this: + + Enter LDAP Password: +adding new entry "dc=example,dc=com" + +adding new entry "cn=Manager,dc=example,dc=com" + + Verify the data was added by issuing a search on the + server using ldapsearch. In this case + the output should look like this: + + &prompt.user; ldapsearch -Z + + # extended LDIF +# +# LDAPv3 +# base <dc=example,dc=com> (default) with scope subtree +# filter: (objectclass=*) +# requesting: ALL +# + +# example.com +dn: dc=example,dc=com +objectClass: dcObject +objectClass: organization +o: Example +dc: Example + +# Manager, example.com +dn: cn=Manager,dc=example,dc=com +objectClass: organizationalRole +cn: Manager + +# search result +search: 3 +result: 0 Success + +# numResponses: 3 +# numEntries: 2 + + It is of course advisable to read about the structure of + LDAP directories and the various manual + pages mentioned in this section. At this point, the server + should be configured and functioning properly. + + + Greg Sutter Written by Automatic Network Configuration (DHCP) What Is DHCP? Dynamic Host Configuration Protocol DHCP Internet Systems Consortium (ISC) 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 uses 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. What This Section Covers 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-dhcp42-server port. The &man.dhclient.8;, &man.dhcp-options.5;, and &man.dhclient.conf.5; manual pages, in addition to the references below, are useful resources. How It Works UDP 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 &man.dhcp-options.5;. FreeBSD Integration &os; fully integrates the OpenBSD DHCP client, dhclient. 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. sysinstall 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 + There are two things required to have the system use DHCP upon startup: DHCP requirements Make sure that the bpf - device is compiled into your kernel. To do this, add - device bpf to your kernel + device is compiled into the kernel. To do this, add + device bpf to the kernel configuration file, and rebuild the kernel. For more information about building kernels, see . The bpf device is already part of the GENERIC kernel that is supplied - with FreeBSD, so if you do not have a custom kernel, you - should not need to create one in order to get DHCP - working. + with &os;, thus there is no need to build a custom kernel + for DHCP. In the case of a custom + kernel configuration file, this device must be present + for DHCP to function properly. + For those who are particularly security conscious, - you should be warned that bpf + take note that bpf is also the device that allows packet sniffers to work correctly (although they still have to be run as root). bpf is - required to use DHCP, but if you are very sensitive - about security, you probably should not add - bpf to your + required to use DHCP; however, the security sensitive + types should probably not add + bpf to the kernel in the expectation that at some point in the - future you will be using DHCP. + future the system will be using DHCP. + By default, DHCP configuration on &os; runs in the background, or asynchronously. Other startup scripts continue to run while DHCP completes, speeding up system startup. Background DHCP works well when the DHCP server responds quickly to requests and the DHCP configuration process goes quickly. However, DHCP may take a long time to complete on some systems. If network services attempt to run before DHCP has completed, they will fail. Using DHCP in synchronous mode prevents the problem, pausing startup until DHCP configuration has completed. To connect to a DHCP server in the background while other startup continues (asynchronous mode), use the DHCP value in /etc/rc.conf: ifconfig_fxp0="DHCP" To pause startup while DHCP completes, use synchronous mode with the SYNCDHCP value: ifconfig_fxp0="SYNCDHCP" Replace the fxp0 shown in these examples with the name of the interface to be dynamically configured, as described in . - If you are using a different location for - dhclient, or if you wish to pass - additional flags to dhclient, also + When using a different file system location for + dhclient, or if + additional flags must be passed to + dhclient, include (editing as necessary): dhclient_program="/sbin/dhclient" dhclient_flags="" DHCP server The DHCP server, dhcpd, is included as part of the net/isc-dhcp42-server port in the ports collection. This port contains the ISC DHCP server and documentation. Files DHCP configuration files /etc/dhclient.conf dhclient requires a configuration file, /etc/dhclient.conf. Typically the file contains only comments, the defaults being reasonably sane. This configuration file is described by the &man.dhclient.conf.5; manual page. /sbin/dhclient dhclient is statically linked and resides in /sbin. The &man.dhclient.8; manual page gives more information about dhclient. /sbin/dhclient-script dhclient-script is the FreeBSD-specific DHCP client configuration script. It is described in &man.dhclient-script.8;, but should not need any user modification to function properly. /var/db/dhclient.leases.interface The DHCP client keeps a database of valid leases in this file, which is written as a log. &man.dhclient.leases.5; gives a slightly longer description. Further Reading The DHCP protocol is fully described in RFC 2131. An informational resource has also been set up at . Installing and Configuring a DHCP Server What This Section Covers This section provides information on how to configure a FreeBSD system to act as a DHCP server using the ISC (Internet Systems Consortium) implementation of the DHCP server. - The server is not provided as part of FreeBSD, and so - you will need to install the net/isc-dhcp42-server port to - provide this service. See for + The server is not provided as part of &os;, and so + the net/isc-dhcp42-server port must + be installed to provide this service. + See for more information on using the Ports Collection. DHCP Server Installation DHCP installation - In order to configure your FreeBSD system as a DHCP - server, you will need to ensure that the &man.bpf.4; - device is compiled into your kernel. To do this, add - device bpf to your kernel + In order to configure the &os; system as a DHCP + server, first ensure that the &man.bpf.4; + device is compiled into the kernel. To do this, add + device bpf to the kernel configuration file, and rebuild the kernel. For more information about building kernels, see . The bpf device is already part of the GENERIC kernel that is - supplied with FreeBSD, so you do not need to create a - custom kernel in order to get DHCP working. + supplied with &os;, so there is no need to create a + custom kernel in order to get DHCP + working. Those who are particularly security conscious should note that bpf is also - the device that allows packet sniffers to work + the device that allows packet sniffers to function correctly (although such programs still need - privileged access). bpf - is required to use DHCP, but if - you are very sensitive about security, you probably - should not include bpf in - your kernel purely because you expect to use DHCP at - some point in the future. + privileged access). The bpf + device is required to use DHCP, but + if the sensitivity of the system's security is high, this + device should not be included in + the kernel purely because the use of + DHCP may, at + some point in the future, be desired. - The next thing that you will need to do is edit the + The next thing that is needed is to edit the sample dhcpd.conf which was installed by the net/isc-dhcp42-server port. By default, this will be /usr/local/etc/dhcpd.conf.sample, and you should copy this to /usr/local/etc/dhcpd.conf before proceeding to make changes. Configuring the DHCP Server DHCP dhcpd.conf dhcpd.conf is comprised of declarations regarding subnets and hosts, and is perhaps most easily explained using an example : option domain-name "example.com"; option domain-name-servers 192.168.4.100; option subnet-mask 255.255.255.0; default-lease-time 3600; max-lease-time 86400; ddns-update-style none; subnet 192.168.4.0 netmask 255.255.255.0 { range 192.168.4.129 192.168.4.254; option routers 192.168.4.1; } host mailhost { hardware ethernet 02:03:04:05:06:07; fixed-address mailhost.example.com; } This option specifies the domain that will be provided to clients as the default search domain. See &man.resolv.conf.5; for more information on what this means. This option specifies a comma separated list of DNS servers that the client should use. The netmask that will be provided to clients. A client may request a specific length of time that a lease will be valid. Otherwise the server will assign a lease with this expiry value (in seconds). This is the maximum length of time that the server will lease for. Should a client request a longer lease, a lease will be issued, although it will only be valid for max-lease-time seconds. This option specifies whether the DHCP server should attempt to update DNS when a lease is accepted or released. In the ISC implementation, this option is required. This denotes which IP addresses should be used in the pool reserved for allocating to clients. IP addresses between, and including, the ones stated are handed out to clients. Declares the default gateway that will be provided to clients. The hardware MAC address of a host (so that the DHCP server can recognize a host when it makes a request). Specifies that the host should always be given the same IP address. Note that using a hostname is correct here, since the DHCP server will resolve the hostname itself before returning the lease information. - Once you have finished writing your - dhcpd.conf, - you should enable the DHCP server in + Once the configuration of + dhcpd.conf has been completed, + enable the DHCP server in /etc/rc.conf, i.e., by adding: dhcpd_enable="YES" dhcpd_ifaces="dc0" Replace the dc0 interface name with the interface (or interfaces, separated by whitespace) - that your DHCP server should listen on for DHCP client + that the DHCP server should listen on for DHCP client requests. - Then, you can proceed to start the server by issuing + Proceed to start the server by issuing the following command: &prompt.root; service isc-dhcpd start - Should you need to make changes to the configuration - of your server in the future, it is important to note that - sending a SIGHUP signal to - dhcpd does - not result in the configuration being - reloaded, as it does with most daemons. You will need to - send a SIGTERM signal to stop the - process, and then restart it using the command - above. + Any future changes to the configuration + of the server will require the sending of a + SIGTERM signal to + dhcpd rather than a + SIGHUP. It is definitely more + simple to use &man.service.8; to completely restart + the service. Files DHCP configuration files /usr/local/sbin/dhcpd dhcpd is statically linked and resides in /usr/local/sbin. The &man.dhcpd.8; manual page installed with the port gives more information about dhcpd. /usr/local/etc/dhcpd.conf dhcpd requires a configuration file, /usr/local/etc/dhcpd.conf before it will start providing service to clients. This file needs to contain all the information that should be provided to clients that are being serviced, along with information regarding the operation of the server. This configuration file is described by the &man.dhcpd.conf.5; manual page installed by the port. /var/db/dhcpd.leases The DHCP server keeps a database of leases it has issued in this file, which is written as a log. The manual page &man.dhcpd.leases.5;, installed by the port gives a slightly longer description. /usr/local/sbin/dhcrelay dhcrelay is used in advanced environments where one DHCP server forwards a request from a client to another DHCP server on a - separate network. If you require this functionality, + separate network. If this functionality is required, then install the net/isc-dhcp42-relay port. The &man.dhcrelay.8; manual page provided with the port contains more detail. Chern Lee Contributed by Tom Rhodes Daniel Gerzo Domain Name System (<acronym>DNS</acronym>) Overview BIND &os; 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 &os; 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. &os; currently comes with BIND9 DNS server software by default. Our installation provides enhanced security features, a new file system layout and automated &man.chroot.8; configuration. DNS 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 Systems Consortium . Terminology To understand this document, some terms related to DNS must be understood. resolver reverse DNS root zone Term Definition Forward DNS Mapping of hostnames to IP addresses. Origin Refers to the domain covered in a particular zone file. named, BIND Common names for the BIND name server package within &os;. Resolver A system process through which a machine queries a name server for zone information. Reverse DNS Mapping of IP addresses to hostnames. Root zone The beginning of the Internet zone hierarchy. All zones fall under the root zone, similar to how all files in a file system fall under the root directory. Zone An individual domain, subdomain, or portion of the DNS administered by the same authority. zones examples Examples of zones: . is how the root zone is usually referred to in documentation. org. is a Top Level Domain (TLD) under the root zone. example.org. is a zone under the org. TLD. 1.168.192.in-addr.arpa is a zone referencing all IP addresses which fall under the 192.168.1.* IP address space. 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. Reasons to Run a Name Server Name servers generally come in two forms: authoritative name servers, and caching (also known as resolving) name servers. An authoritative name server is needed when: One wants to serve DNS information to the world, replying authoritatively to queries. A domain, such as example.org, is registered and IP addresses need to be assigned to hostnames under it. An IP address block requires reverse DNS entries (IP to hostname). A backup or second name server, called a slave, will reply to queries. A caching name server is needed when: A local DNS server may cache and respond more quickly than querying an outside name server. 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. Additional queries will not have to go outside the local network, since the information is cached locally. How It Works In &os;, the BIND daemon is called named. File Description &man.named.8; The BIND daemon. &man.rndc.8; Name server control utility. /etc/namedb Directory where BIND zone information resides. /etc/namedb/named.conf Configuration file of the daemon. 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. Starting BIND BIND starting Since BIND is installed by default, configuring it is relatively simple. The default named configuration is that of a basic resolving name server, running in a &man.chroot.8; environment, and restricted to listening on the local IPv4 loopback address (127.0.0.1). To start the server one time with this configuration, use the following command: &prompt.root; service named onestart To ensure the named daemon is started at boot each time, put the following line into the /etc/rc.conf: named_enable="YES" 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 + the scope of this document. There are other startup options + for named on &os;, take a look at the named_* flags in /etc/defaults/rc.conf and consult the &man.rc.conf.5; manual page. The section is also a good read. Configuration Files BIND configuration files 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. <filename>/etc/namedb/named.conf</filename> // $FreeBSD$ // // Refer to the named.conf(5) and named(8) man pages, and the documentation // in /usr/share/doc/bind9 for more details. // // If you are going to set up an authoritative server, make sure you // understand the hairy details of how DNS works. Even with // simple mistakes, you can break connectivity for affected parties, // or cause huge amounts of useless Internet traffic. options { // All file and path names are relative to the chroot directory, // if any, and should be fully qualified. directory "/etc/namedb/working"; pid-file "/var/run/named/pid"; dump-file "/var/dump/named_dump.db"; statistics-file "/var/stats/named.stats"; // If named is being used only as a local resolver, this is a safe default. // For named to be accessible to the network, comment this option, specify // the proper IP address, or delete this option. listen-on { 127.0.0.1; }; // If you have IPv6 enabled on this system, uncomment this option for // use as a local resolver. To give access to the network, specify // an IPv6 address, or the keyword "any". // listen-on-v6 { ::1; }; // These zones are already covered by the empty zones listed below. // If you remove the related empty zones below, comment these lines out. disable-empty-zone "255.255.255.255.IN-ADDR.ARPA"; disable-empty-zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA"; disable-empty-zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA"; // If you've got a DNS server around at your upstream provider, enter // its IP address here, and enable the line below. This will make you // benefit from its cache, thus reduce overall DNS traffic in the Internet. /* forwarders { 127.0.0.1; }; */ // If the 'forwarders' clause is not empty the default is to 'forward first' // which will fall back to sending a query from your local server if the name // servers in 'forwarders' do not have the answer. Alternatively you can // force your name server to never initiate queries of its own by enabling the // following line: // forward only; // If you wish to have forwarding configured automatically based on // the entries in /etc/resolv.conf, uncomment the following line and // set named_auto_forward=yes in /etc/rc.conf. You can also enable // named_auto_forward_only (the effect of which is described above). // include "/etc/namedb/auto_forward.conf"; Just as the comment says, to benefit from an uplink's cache, forwarders can be enabled here. Under normal circumstances, a name server will recursively query the Internet looking at certain name servers until it finds the answer it is looking for. Having this enabled will have it query the uplink's name server (or name server provided) first, taking advantage of its cache. If the uplink name server in question is a heavily trafficked, fast name server, enabling this may be worthwhile. 127.0.0.1 will not work here. Change this - IP address to a name server at your + IP address to a name server at the uplink. /* Modern versions of BIND use a random UDP port for each outgoing query by default in order to dramatically reduce the possibility of cache poisoning. All users are strongly encouraged to utilize this feature, and to configure their firewalls to accommodate it. AS A LAST RESORT in order to get around a restrictive firewall policy you can try enabling the option below. Use of this option will significantly reduce your ability to withstand cache poisoning attacks, and should be avoided if at all possible. Replace NNNNN in the example with a number between 49160 and 65530. */ // query-source address * port NNNNN; }; // If you enable a local name server, don't forget to enter 127.0.0.1 // first in your /etc/resolv.conf so this server will be queried. // Also, make sure to enable it in /etc/rc.conf. // The traditional root hints mechanism. Use this, OR the slave zones below. zone "." { type hint; file "/etc/namedb/named.root"; }; /* Slaving the following zones from the root name servers has some significant advantages: 1. Faster local resolution for your users 2. No spurious traffic will be sent from your network to the roots 3. Greater resilience to any potential root server failure/DDoS On the other hand, this method requires more monitoring than the hints file to be sure that an unexpected failure mode has not incapacitated your server. Name servers that are serving a lot of clients will benefit more from this approach than individual hosts. Use with caution. To use this mechanism, uncomment the entries below, and comment the hint zone above. As documented at http://dns.icann.org/services/axfr/ these zones: "." (the root), ARPA, IN-ADDR.ARPA, IP6.ARPA, and ROOT-SERVERS.NET are available for AXFR from these servers on IPv4 and IPv6: xfr.lax.dns.icann.org, xfr.cjr.dns.icann.org */ /* zone "." { type slave; file "/etc/namedb/slave/root.slave"; masters { 192.5.5.241; // F.ROOT-SERVERS.NET. }; notify no; }; zone "arpa" { type slave; file "/etc/namedb/slave/arpa.slave"; masters { 192.5.5.241; // F.ROOT-SERVERS.NET. }; notify no; }; */ /* Serving the following zones locally will prevent any queries for these zones leaving your network and going to the root name servers. This has two significant advantages: 1. Faster local resolution for your users 2. No spurious traffic will be sent from your network to the roots */ // RFCs 1912 and 5735 (and BCP 32 for localhost) zone "localhost" { type master; file "/etc/namedb/master/localhost-forward.db"; }; zone "127.in-addr.arpa" { type master; file "/etc/namedb/master/localhost-reverse.db"; }; zone "255.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // RFC 1912-style zone for IPv6 localhost address zone "0.ip6.arpa" { type master; file "/etc/namedb/master/localhost-reverse.db"; }; // "This" Network (RFCs 1912 and 5735) zone "0.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // Private Use Networks (RFCs 1918 and 5735) zone "10.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "16.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "17.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "18.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "19.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "20.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "21.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "22.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "23.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "24.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "25.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "26.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "27.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "28.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "29.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "30.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "31.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "168.192.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // Link-local/APIPA (RFCs 3927 and 5735) zone "254.169.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // IETF protocol assignments (RFCs 5735 and 5736) zone "0.0.192.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // TEST-NET-[1-3] for Documentation (RFCs 5735 and 5737) zone "2.0.192.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "100.51.198.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "113.0.203.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // IPv6 Range for Documentation (RFC 3849) zone "8.b.d.0.1.0.0.2.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // Domain Names for Documentation and Testing (BCP 32) zone "test" { type master; file "/etc/namedb/master/empty.db"; }; zone "example" { type master; file "/etc/namedb/master/empty.db"; }; zone "invalid" { type master; file "/etc/namedb/master/empty.db"; }; zone "example.com" { type master; file "/etc/namedb/master/empty.db"; }; zone "example.net" { type master; file "/etc/namedb/master/empty.db"; }; zone "example.org" { type master; file "/etc/namedb/master/empty.db"; }; // Router Benchmark Testing (RFCs 2544 and 5735) zone "18.198.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "19.198.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // IANA Reserved - Old Class E Space (RFC 5735) zone "240.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "241.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "242.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "243.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "244.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "245.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "246.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "247.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "248.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "249.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "250.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "251.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "252.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "253.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "254.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // IPv6 Unassigned Addresses (RFC 4291) zone "1.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "3.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "4.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "5.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "6.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "7.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "8.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "9.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "a.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "b.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "c.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "d.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "e.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "0.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "1.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "2.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "3.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "4.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "5.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "6.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "7.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "8.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "9.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "a.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "b.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "0.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "1.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "2.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "3.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "4.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "5.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "6.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "7.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // IPv6 ULA (RFC 4193) zone "c.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "d.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // IPv6 Link Local (RFC 4291) zone "8.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "9.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "a.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "b.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // IPv6 Deprecated Site-Local Addresses (RFC 3879) zone "c.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "d.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "e.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "f.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // IP6.INT is Deprecated (RFC 4159) zone "ip6.int" { type master; file "/etc/namedb/master/empty.db"; }; // NB: Do not use the IP addresses below, they are faked, and only // serve demonstration/documentation purposes! // // Example slave zone config entries. It can be convenient to become // a slave at least for the zone your own domain is in. Ask // your network administrator for the IP address of the responsible // master name server. // // Do not forget to include the reverse lookup zone! // This is named after the first bytes of the IP address, in reverse // order, with ".IN-ADDR.ARPA" appended, or ".IP6.ARPA" for IPv6. // // Before starting to set up a master zone, make sure you fully // understand how DNS and BIND work. There are sometimes // non-obvious pitfalls. Setting up a slave zone is usually simpler. // // NB: Don't blindly enable the examples below. :-) Use actual names // and addresses instead. /* An example dynamic zone key "exampleorgkey" { algorithm hmac-md5; secret "sf87HJqjkqh8ac87a02lla=="; }; zone "example.org" { type master; allow-update { key "exampleorgkey"; }; file "/etc/namedb/dynamic/example.org"; }; */ /* Example of a slave reverse zone zone "1.168.192.in-addr.arpa" { type slave; file "/etc/namedb/slave/1.168.192.in-addr.arpa"; masters { 192.168.1.1; }; }; */ In named.conf, these are examples of slave entries for a forward and reverse zone. For each new zone served, a new zone entry must be added to named.conf. For example, the simplest zone entry for example.org can look like: zone "example.org" { type master; file "master/example.org"; }; The zone is a master, as indicated by the statement, holding its zone information in /etc/namedb/master/example.org indicated by the statement. zone "example.org" { type slave; file "slave/example.org"; }; In the slave case, the zone information is transferred from the master name server for the particular zone, and saved in the file specified. If and when the master server dies or is unreachable, the slave name server will have the transferred zone information and will be able to serve it. Zone Files BIND zone files An example master zone file for example.org (existing within /etc/namedb/master/example.org) is as follows: $TTL 3600 ; 1 hour default TTL example.org. IN SOA ns1.example.org. admin.example.org. ( 2006051501 ; Serial 10800 ; Refresh 3600 ; Retry 604800 ; Expire 300 ; Negative Response TTL ) ; DNS Servers IN NS ns1.example.org. IN NS ns2.example.org. ; MX Records IN MX 10 mx.example.org. IN MX 20 mail.example.org. IN A 192.168.1.1 ; Machine Names localhost IN A 127.0.0.1 ns1 IN A 192.168.1.2 ns2 IN A 192.168.1.3 mx IN A 192.168.1.4 mail IN A 192.168.1.5 ; Aliases www IN CNAME example.org. Note that every hostname ending in a . is an exact hostname, whereas everything without a trailing . is relative to the origin. For example, ns1 is translated into ns1.example.org. The format of a zone file follows: recordname IN recordtype value DNS records The most commonly used DNS records: SOA start of zone authority NS an authoritative name server A a host address CNAME the canonical name for an alias MX mail exchanger PTR a domain name pointer (used in reverse DNS) example.org. IN SOA ns1.example.org. admin.example.org. ( 2006051501 ; Serial 10800 ; Refresh after 3 hours 3600 ; Retry after 1 hour 604800 ; Expire after 1 week 300 ) ; Negative Response TTL example.org. the domain name, also the origin for this zone file. ns1.example.org. the primary/authoritative name server for this zone. admin.example.org. the responsible person for this zone, email address with @ replaced. (admin@example.org becomes admin.example.org) 2006051501 the serial number of the file. This must be incremented each time the zone file is modified. Nowadays, many admins prefer a yyyymmddrr format for the serial number. 2006051501 would mean last modified 05/15/2006, the latter 01 being the first time the zone file has been modified this day. The serial number is important as it alerts slave name servers for a zone when it is updated. IN NS ns1.example.org. This is an NS entry. Every name server that is going to reply authoritatively for the zone must have one of these entries. localhost IN A 127.0.0.1 ns1 IN A 192.168.1.2 ns2 IN A 192.168.1.3 mx IN A 192.168.1.4 mail IN A 192.168.1.5 The A record indicates machine names. As seen above, ns1.example.org would resolve to 192.168.1.2. IN A 192.168.1.1 This line assigns IP address 192.168.1.1 to the current origin, in this case example.org. www IN CNAME @ The canonical name record is usually used for giving aliases to a machine. In the example, www is aliased to the master machine whose name happens to be the same as the domain name example.org (192.168.1.1). CNAMEs can never be used together with another kind of record for the same hostname. MX record IN MX 10 mail.example.org. The MX record indicates which mail servers are responsible for handling incoming mail for the zone. mail.example.org is the hostname of a mail server, and 10 is the priority of that mail server. One can have several mail servers, with priorities of 10, 20 and so on. A mail server attempting to deliver to example.org would first try the highest priority MX (the record with the lowest priority number), then the second highest, etc, until the mail can be properly delivered. For in-addr.arpa zone files (reverse DNS), the same format is used, except with PTR entries instead of A or CNAME. $TTL 3600 1.168.192.in-addr.arpa. IN SOA ns1.example.org. admin.example.org. ( 2006051501 ; Serial 10800 ; Refresh 3600 ; Retry 604800 ; Expire 300 ) ; Negative Response TTL IN NS ns1.example.org. IN NS ns2.example.org. 1 IN PTR example.org. 2 IN PTR ns1.example.org. 3 IN PTR ns2.example.org. 4 IN PTR mx.example.org. 5 IN PTR mail.example.org. This file gives the proper IP address to hostname mappings for the above fictitious domain. It is worth noting that all names on the right side of a PTR record need to be fully qualified (i.e., end in a .). Caching Name Server BIND caching name server A caching name server is a name server whose primary role is to resolve recursive queries. It simply asks queries of its own, and remembers the answers for later use. <acronym role="Domain Name Security Extensions">DNSSEC</acronym> BIND DNS security extensions Domain Name System Security Extensions, or DNSSEC for short, is a suite of specifications to protect resolving name servers from forged DNS data, such as spoofed DNS records. By using digital signatures, a resolver can verify the integrity of the record. Note that DNSSEC only provides integrity via digitally signing the Resource Records (RRs). It provides neither confidentiality nor protection against false end-user assumptions. This means that it cannot protect against people going to example.net instead of example.com. The only thing DNSSEC does is authenticate that the data has not been compromised in transit. The security of DNS is an important step in securing the Internet in general. For more in-depth details of how DNSSEC works, the relevant RFCs are a good place to start. See the list in . The following sections will demonstrate how to enable DNSSEC for an authoritative DNS server and a recursive (or caching) DNS server running BIND 9. While all versions of BIND 9 support DNSSEC, it is necessary to have at least version 9.6.2 in order to be able to use the signed root zone when validating DNS queries. This is because earlier versions lack the required algorithms to enable validation using the root zone key. It is strongly recommended to use the latest version of BIND 9.7 or later to take advantage of automatic key updating for the root key, as well as other features to automatically keep zones signed and signatures up to date. Where configurations differ between 9.6.2 and 9.7 and later, differences will be pointed out. Recursive <acronym>DNS</acronym> Server Configuration Enabling DNSSEC validation of queries performed by a recursive DNS server requires a few changes to named.conf. Before making these changes the root zone key, or trust anchor, must be acquired. Currently the root zone key is not available in a file format BIND understands, so it has to be manually converted into the proper format. The key itself can be obtained by querying the root zone for it using dig. By running &prompt.user; dig +multi +noall +answer DNSKEY . > root.dnskey the key will end up in root.dnskey. The contents should look something like this: . 93910 IN DNSKEY 257 3 8 ( AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQ bSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh /RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWA JQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXp oY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3 LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGO Yl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGc LmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0= ) ; key id = 19036 . 93910 IN DNSKEY 256 3 8 ( AwEAAcaGQEA+OJmOzfzVfoYN249JId7gx+OZMbxy69Hf UyuGBbRN0+HuTOpBxxBCkNOL+EJB9qJxt+0FEY6ZUVjE g58sRr4ZQ6Iu6b1xTBKgc193zUARk4mmQ/PPGxn7Cn5V EGJ/1h6dNaiXuRHwR+7oWh7DnzkIJChcTqlFrXDW3tjt ) ; key id = 34525 Do not be alarmed if the obtained keys differ from this example. They might have changed since these instructions were last updated. This output actually contains two keys. The first key in the listing, with the value 257 after the DNSKEY record type, is the one needed. This value indicates that this is a Secure Entry Point (SEP), commonly known as a Key Signing Key (KSK). The second key, with value 256, is a subordinate key, commonly called a Zone Signing Key (ZSK). More on the different key types later in . Now the key must be verified and formatted so that BIND can use it. To verify the key, generate a DS RR set. Create a file containing these RRs with &prompt.user; dnssec-dsfromkey -f root-dnskey . > root.ds These records use SHA-1 and SHA-256 respectively, and should look similar to the following example, where the longer is using SHA-256. . IN DS 19036 8 1 B256BD09DC8DD59F0E0F0D8541B8328DD986DF6E . IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5 The SHA-256 RR can now be compared to the digest in https://data.iana.org/root-anchors/root-anchors.xml. To be absolutely sure that the key has not been tampered with the data in the XML file can be verified using the PGP signature in https://data.iana.org/root-anchors/root-anchors.asc. Next, the key must be formatted properly. This differs a little between BIND versions 9.6.2 and 9.7 and later. In version 9.7 support was added to automatically track changes to the key and update it as necessary. This is done using managed-keys as seen in the example below. When using the older version, the key is added using a trusted-keys statement and updates must be done manually. For BIND 9.6.2 the format should look like: trusted-keys { "." 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0="; }; For 9.7 the format will instead be: managed-keys { "." initial-key 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0="; }; The root key can now be added to named.conf either directly or by including a file containing the key. After these steps, configure BIND to do DNSSEC validation on queries by editing named.conf and adding the following to the options directive: dnssec-enable yes; dnssec-validation yes; To verify that it is actually working use dig to make a query for a signed zone using the resolver just configured. A successful reply will contain the AD flag to indicate the data was authenticated. Running a query such as &prompt.user; dig @resolver +dnssec se ds should return the DS RR for the .se zone. In the flags: section the AD flag should be set, as seen in: ... ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 ... The resolver is now capable of authenticating DNS queries. Authoritative <acronym>DNS</acronym> Server Configuration In order to get an authoritative name server to serve a DNSSEC signed zone a little more work is required. A zone is signed using cryptographic keys which must be generated. It is possible to use only one key for this. The preferred method however is to have a strong well-protected Key Signing Key (KSK) that is not rotated very often and a Zone Signing Key (ZSK) that is rotated more frequently. Information on recommended operational practices can be found in RFC 4641: DNSSEC Operational Practices. Practices regarding the root zone can be found in DNSSEC Practice Statement for the Root Zone KSK operator and DNSSEC Practice Statement for the Root Zone ZSK operator. The KSK is used to build a chain of authority to the data in need of validation and as such is also called a Secure Entry Point (SEP) key. A message digest of this key, called a Delegation Signer (DS) record, must be published in the parent zone to establish the trust chain. How this is accomplished depends on the parent zone owner. The ZSK is used to sign the zone, and only needs to be published there. To enable DNSSEC for the example.com zone depicted in previous examples, the first step is to use dnssec-keygen to generate the KSK and ZSK key pair. This key pair can utilize different cryptographic algorithms. It is recommended to use RSA/SHA256 for the keys and 2048 bits key length should be enough. To generate the KSK for example.com, run &prompt.user; dnssec-keygen -f KSK -a RSASHA256 -b 2048 -n ZONE example.com and to generate the ZSK, run &prompt.user; dnssec-keygen -a RSASHA256 -b 2048 -n ZONE example.com dnssec-keygen outputs two files, the public and the private keys in files named similar to Kexample.com.+005+nnnnn.key (public) and Kexample.com.+005+nnnnn.private (private). The nnnnn part of the file name is a five digit key ID. Keep track of which key ID belongs to which key. This is especially important when having more than one key in a zone. It is also possible to rename the keys. For each KSK file do: &prompt.user; mv Kexample.com.+005+nnnnn.key Kexample.com.+005+nnnnn.KSK.key &prompt.user; mv Kexample.com.+005+nnnnn.private Kexample.com.+005+nnnnn.KSK.private For the ZSK files, substitute KSK for ZSK as necessary. The files can now be included in the zone file, using the $include statement. It should look something like this: $include Kexample.com.+005+nnnnn.KSK.key ; KSK $include Kexample.com.+005+nnnnn.ZSK.key ; ZSK Finally, sign the zone and tell BIND to use the signed zone file. To sign a zone dnssec-signzone is used. The command to sign the zone example.com, located in example.com.db would look similar to &prompt.user; dnssec-signzone -o example.com -k Kexample.com.+005+nnnnn.KSK example.com.db Kexample.com.+005+nnnnn.ZSK.key The key supplied to the argument is the KSK and the other key file is the ZSK that should be used in the signing. It is possible to supply more than one KSK and ZSK, which will result in the zone being signed with all supplied keys. This can be needed to supply zone data signed using more than one algorithm. The output of dnssec-signzone is a zone file with all RRs signed. This output will end up in a file with the extension .signed, such as example.com.db.signed. The DS records will also be written to a separate file dsset-example.com. To use this signed zone just modify the zone directive in named.conf to use example.com.db.signed. By default, the signatures are only valid 30 days, meaning that the zone needs to be resigned in about 15 days to be sure that resolvers are not caching records with stale signatures. It is possible to make a script and a cron job to do this. See relevant manuals for details. Be sure to keep private keys confidential, as with all cryptographic keys. When changing a key it is best to include the new key into the zone, while still signing with the old one, and then move over to using the new key to sign. After these steps are done the old key can be removed from the zone. Failure to do this might render the DNS data unavailable for a time, until the new key has propagated through the DNS hierarchy. For more information on key rollovers and other DNSSEC operational issues, see RFC 4641: DNSSEC Operational practices. Automation Using <acronym>BIND</acronym> 9.7 or Later Beginning with BIND version 9.7 a new feature called Smart Signing was introduced. This feature aims to make the key management and signing process simpler by automating parts of the task. By putting the keys into a directory called a key repository, and using the new option auto-dnssec, it is possible to create a dynamic zone which will be resigned as needed. To update this zone use nsupdate with the new option . rndc has also grown the ability to sign zones with keys in the key repository, using the option . To tell BIND to use this automatic signing and zone updating for example.com, add the following to named.conf: zone example.com { type master; key-directory "/etc/named/keys"; update-policy local; auto-dnssec maintain; file "/etc/named/dynamic/example.com.zone"; }; After making these changes, generate keys for the zone as explained in , put those keys in the key repository given as the argument to the key-directory in the zone configuration and the zone will be signed automatically. Updates to a zone configured this way must be done using nsupdate, which will take care of re-signing the zone with the new data added. For further details, see and the BIND documentation. Security 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 &os; automatically drops named into a &man.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 &a.security-notifications; to stay up to date with the current Internet and &os; security issues. If a problem arises, keeping sources up to date and having a fresh build of named may help. Further Reading BIND/named manual pages: &man.rndc.8; &man.named.8; &man.named.conf.5; &man.nsupdate.1; &man.dnssec-signzone.8; &man.dnssec-keygen.8; Official ISC BIND Page Official ISC BIND Forum O'Reilly DNS and BIND 5th Edition Root DNSSEC DNSSEC Trust Anchor Publication for the Root Zone RFC1034 - Domain Names - Concepts and Facilities RFC1035 - Domain Names - Implementation and Specification RFC4033 - DNS Security Introduction and Requirements RFC4034 - Resource Records for the DNS Security Extensions RFC4035 - Protocol Modifications for the DNS Security Extensions RFC4641 - DNSSEC Operational Practices RFC 5011 - Automated Updates of DNS Security (DNSSEC Trust Anchors Murray Stokely Contributed by Apache HTTP Server web servers setting up Apache Overview &os; is used to run some of the busiest web sites in the world. The majority of web servers on the Internet are using the Apache HTTP Server. Apache software packages should be - included on your FreeBSD installation media. If you did not - install Apache when you first - installed FreeBSD, then you can install it from the Apache was not installed while + installing &os;, then it can be installed from the www/apache22 port. Once Apache has been installed successfully, it must be configured. This section covers version 2.2.X of the Apache HTTP Server as that is the most widely used version for &os;. For more detailed information beyond the scope of this document about Apache 2.X, please see . Configuration Apache configuration file The main Apache HTTP Server configuration file is installed as /usr/local/etc/apache22/httpd.conf on &os;. This file is a typical &unix; text configuration file with comment lines beginning with the # character. A comprehensive description of all possible configuration options is outside the scope of this book, so only the most frequently modified directives will be described here. ServerRoot "/usr/local" This specifies the default directory hierarchy for the Apache installation. Binaries are stored in the bin and sbin subdirectories of the server root, and configuration files are stored in etc/apache. ServerAdmin you@your.address The address to which problems with the server should - be emailed. This address appears on some + be emailed. This address also appears on some server-generated pages, such as error documents. ServerName www.example.com - ServerName allows you to set a - host name which is sent back to clients for your server - if it is different than the one that the host is - configured with (i.e., use www instead + ServerName allows an administrator + to set a host name which is sent back to clients for the + server. This is useful if the host is different than the + one that it is configured with (i.e., use + www instead of the host's real name). DocumentRoot "/usr/local/www/apache22/data" - DocumentRoot: The directory out - of which you will serve your documents. By default, all + DocumentRoot: The directory + where documents will be served from. By default, all requests are taken from this directory, but symbolic links and aliases may be used to point to other locations. - It is always a good idea to make backup copies of your + It is always a good idea to make backup copies of the Apache configuration file before - making changes. Once you are satisfied with your initial - configuration you are ready to start running - Apache. + making changes. When the configuration of + Apache, is complete, save the + file and verify the configuration using &man.apachectl.8;. + To do this, issue apachectl configtest + which should return Syntax OK. Running <application>Apache</application> Apache starting or stopping The www/apache22 port installs an &man.rc.8; script to aid in starting, stopping, and restarting Apache, which can be found in /usr/local/etc/rc.d/. To launch Apache at system startup, add the following line to /etc/rc.conf: apache22_enable="YES" If Apache should be started with non-default options, the following line may be added to /etc/rc.conf: apache22_flags="" The Apache configuration can be - tested for errors before starting the httpd - daemon for the first time, or after making subsequent + tested for errors after making subsequent configuration changes while httpd is running. This can be done by the &man.rc.8; script directly, or by the &man.service.8; utility by issuing one of the following commands: &prompt.root; service apache22 configtest It is important to note that the configtest is not an &man.rc.8; standard, and should not be expected to work for all &man.rc.8; startup scripts. If Apache does not report configuration errors, the Apache httpd can be started with &man.service.8;: &prompt.root; service apache22 start The httpd service can be tested by entering http://localhost in a web browser, replacing localhost with the fully-qualified domain name of the machine running httpd, if it is not the local machine. The default web page that is displayed is /usr/local/www/apache22/data/index.html. Virtual Hosting Apache supports two different types of Virtual Hosting. The first method is Name-based Virtual Hosting. Name-based virtual hosting uses the clients HTTP/1.1 headers to figure out the hostname. This allows many different domains to share the same IP address. To setup Apache to use Name-based Virtual Hosting add an entry like the following to - your httpd.conf: + httpd.conf: NameVirtualHost * - If your webserver was named www.domain.tld and you wanted to setup + If the webserver was named www.domain.tld and a virtual domain for www.someotherdomain.tld then you would + role="fqdn">www.someotherdomain.tld then add the following entries to httpd.conf: <VirtualHost *> ServerName www.domain.tld DocumentRoot /www/domain.tld </VirtualHost> <VirtualHost *> ServerName www.someotherdomain.tld DocumentRoot /www/someotherdomain.tld </VirtualHost> - Replace the addresses with the addresses you want to use - and the path to the documents with what you are using. + Replace the addresses with the addresses needed + and the path to the documents with what are being used. For more information about setting up virtual hosts, please consult the official Apache documentation at: . Apache Modules Apache modules There are many different Apache modules available to add functionality to the basic server. The FreeBSD Ports Collection provides an easy way to install Apache together with some of the more popular add-on modules. <application>mod_ssl</application> web servers secure SSL cryptography The mod_ssl module uses the OpenSSL library to provide strong cryptography via the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols. This module provides everything necessary to request a signed certificate from - a trusted certificate signing authority so that you can run + a trusted certificate signing authority to run a secure web server on &os;. The mod_ssl module is built by default, but can be enabled by specifying -DWITH_SSL at compile time. Language Bindings There are Apache modules for most major scripting languages. These modules typically make it possible to write Apache modules entirely in a scripting language. They are also often used as a persistent interpreter embedded into the server that avoids the overhead of starting an external interpreter and the startup-time penalty for dynamic websites, as described in the next section. Dynamic Websites web servers dynamic In the last decade, more businesses have turned to the Internet in order to enhance their revenue and increase exposure. This has also increased the need for interactive web content. While some companies, such as µsoft;, have introduced solutions into their proprietary products, the open source community answered the call. Modern options for dynamic web content include Django, Ruby on Rails, mod_perl2, and mod_php. Django Python Django Django is a BSD licensed framework designed to allow developers to write high performance, elegant web applications quickly. It provides an object-relational mapper so that data types are developed as Python objects, and a rich dynamic database-access API is provided for those objects without the developer ever having to write SQL. It also provides an extensible template system so that the logic of the application is separated from the HTML presentation. Django depends on mod_python, Apache, and an SQL database - engine of your choice. The FreeBSD Port will install all of - these pre-requisites for you with the appropriate + engine. The &os; Port will install all of + these pre-requisites with the appropriate flags. Installing Django with <application>Apache2</application>, <application>mod_python3</application>, and <application>PostgreSQL</application> &prompt.root; cd /usr/ports/www/py-django; make all install clean -DWITH_MOD_PYTHON3 -DWITH_POSTGRESQL - Once Django and these pre-requisites are installed, you - will need to create a Django project directory and then - configure Apache to use the embedded Python interpreter to - call your application for specific URLs on your site. + Once Django and these pre-requisites are installed, + the application will need a Django project directory along + with the Apache configuration to use the embedded Python + interpreter. This will be the interpreter to + call the application for specific URLs on the site. Apache Configuration for Django/mod_python - You will need to add a line to the apache + A line must be added to the apache httpd.conf file to configure Apache - to pass requests for certain URLs to your web + to pass requests for certain URLs to the web application: <Location "/"> SetHandler python-program - PythonPath "['/dir/to/your/django/packages/'] + sys.path" + PythonPath "['/dir/to/the/django/packages/'] + sys.path" PythonHandler django.core.handlers.modpython SetEnv DJANGO_SETTINGS_MODULE mysite.settings PythonAutoReload On PythonDebug On </Location> Ruby on Rails Ruby on Rails Ruby on Rails is another open source web framework that provides a full development stack and is optimized to make web developers more productive and capable of writing powerful applications quickly. It can be installed easily from the ports system. &prompt.root; cd /usr/ports/www/rubygem-rails; make all install clean <application>mod_perl2</application> mod_perl2 Perl The Apache/Perl integration project brings together the full power of the Perl programming language and the Apache HTTP Server. With the mod_perl2 module it is possible to write Apache modules entirely in Perl. In addition, the persistent interpreter embedded in the server avoids the overhead of starting an external interpreter and the penalty of Perl start-up time. mod_perl2 is available in the www/mod_perl2 port. Tom Rhodes Written by <application>mod_php</application> mod_php PHP PHP, also known as PHP: Hypertext Preprocessor is a general-purpose scripting language that is especially suited for Web development. Capable of being embedded into HTML its syntax draws upon C, &java;, and Perl with the intention of allowing web developers to write dynamically generated webpages quickly. To gain support for PHP5 for the Apache web server, begin by installing the lang/php5 port. If the lang/php5 port is being installed for the first time, available OPTIONS will be displayed automatically. If a menu is not displayed, i.e., because the lang/php5 port has been installed some time in the past, it is always possible to bring the options dialog up again by running: &prompt.root; make config in the port directory. In the options dialog, check the APACHE option to build mod_php5 as a loadable module for the Apache web server. A lot of sites are still using PHP4 for various reasons (i.e., compatibility issues or already deployed web applications). If the mod_php4 is needed instead of mod_php5, then please use the lang/php4 port. The lang/php4 port supports many of the configuration and build-time options of the lang/php5 port. This will install and configure the modules required to support dynamic PHP applications. Check to ensure the following sections have been added to /usr/local/etc/apache22/httpd.conf: LoadModule php5_module libexec/apache/libphp5.so AddModule mod_php5.c <IfModule mod_php5.c> DirectoryIndex index.php index.html </IfModule> <IfModule mod_php5.c> AddType application/x-httpd-php .php AddType application/x-httpd-php-source .phps </IfModule> Once completed, a simple call to the apachectl command for a graceful restart is needed to load the PHP module: &prompt.root; apachectl graceful For future upgrades of PHP, the make config command will not be required; the selected OPTIONS are saved automatically by the &os; Ports framework. The PHP support in &os; is extremely modular so the base install is very limited. It is very easy to add support using the lang/php5-extensions port. This port provides a menu driven interface to PHP extension installation. Alternatively, individual extensions can be installed using the appropriate port. For instance, to add support for the MySQL database server to PHP5, simply install the port databases/php5-mysql. After installing an extension, the Apache server must be reloaded to pick up the new configuration changes: &prompt.root; apachectl graceful Murray Stokely Contributed by File Transfer Protocol (FTP) FTP servers Overview The File Transfer Protocol (FTP) provides users with a simple way to transfer files to and from an FTP server. &os; includes FTP server software, ftpd, in the base system. This makes setting up and administering an FTP server on FreeBSD very straightforward. Configuration The most important configuration step is deciding which accounts will be allowed access to the FTP server. A normal - FreeBSD system has a number of system accounts used for + &os; system has a number of system accounts used for various daemons, but unknown users should not be allowed to log in with these accounts. The /etc/ftpusers file is a list of users disallowed any FTP access. By default, it includes the aforementioned system accounts, but it is possible to add specific users here that should not be allowed access to FTP. - You may want to restrict the access of some users without + In some cases it may be desirable to restrict the access + of some users without preventing them completely from using FTP. This can be accomplished with the /etc/ftpchroot file. This file lists users and groups subject to FTP access restrictions. The &man.ftpchroot.5; manual page has all of the details so it will not be described in detail here. FTP anonymous - If you would like to enable anonymous FTP access to your - server, then you must create a user named - ftp on your &os; system. Users will then - be able to log on to your FTP server with a username of + To enable anonymous FTP access to the + server, create a user named + ftp on the &os; system. Users will then + be able to log on to the FTP server with a username of ftp or anonymous and with any password (by convention an email address for the user should be used as the password). The FTP server will call &man.chroot.2; when an anonymous user logs in, to restrict access to only the home directory of the ftp user. There are two text files that specify welcome messages to be displayed to FTP clients. The contents of the file /etc/ftpwelcome will be displayed to users before they reach the login prompt. After a successful login, the contents of the file /etc/ftpmotd will be displayed. Note that the path to this file is relative to the login environment, so the file ~ftp/etc/ftpmotd would be displayed for anonymous users. Once the FTP server has been configured properly, it must be enabled in /etc/inetd.conf. All that is required here is to remove the comment symbol # from in front of the existing ftpd line : ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l As explained in , the inetd configuration must be reloaded after this configuration file is changed. Please refer to for details - on enabling inetd on your + on enabling inetd on the system. Alternatively, ftpd can also be started as a stand-alone server. In this case, it is sufficient to set the appropriate variable in /etc/rc.conf: ftpd_enable="YES" After setting the above variable, the stand-alone server will be started at the next reboot, or it can be started manually by executing the following command as root: &prompt.root; service ftpd start - You can now log on to your FTP server by typing: + You can now log on to the FTP server by typing: &prompt.user; ftp localhost Maintaining syslog log files FTP The ftpd daemon uses &man.syslog.3; to log messages. By default, the system log daemon will put messages related to FTP in the /var/log/xferlog file. The location of the FTP log can be modified by changing the following line in /etc/syslog.conf: ftp.info /var/log/xferlog FTP anonymous Be aware of the potential problems involved with running - an anonymous FTP server. In particular, you should think - twice about allowing anonymous users to upload files. You may - find that your FTP site becomes a forum for the trade of - unlicensed commercial software or worse. If you do need to - allow anonymous FTP uploads, then you should set up the + an anonymous FTP server. In particular, think + twice about allowing anonymous users to upload files. It may + turn out that the FTP site becomes a forum for the trade of + unlicensed commercial software or worse. If anonymous + FTP uploads are required, then verify the permissions so that these files can not be read by other - anonymous users until they have been reviewed. + anonymous users until they have been reviewed by an + administrator. Murray Stokely Contributed by File and Print Services for µsoft.windows; Clients (Samba) Samba server Microsoft Windows file server Windows clients print server Windows clients Overview Samba is a popular open source software package that provides file and print services for µsoft.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. + use &os; filespace as if it was a local disk drive, or + &os; 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/samba34 port or package. Configuration A default Samba configuration file is installed as /usr/local/share/examples/samba34/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 + printers and file system shares that will + be shared with &windows; clients. The Samba package includes a web based tool called swat which provides a simple way of configuring the smb.conf file. Using the Samba Web Administration Tool (SWAT) The Samba Web Administration Tool (SWAT) runs as a daemon from inetd. Therefore, inetd must be enabled as shown in , and the following line in /etc/inetd.conf should be uncommented before swat can be used to configure Samba: swat stream tcp nowait/400 root /usr/local/sbin/swat swat As explained in , the inetd configuration must be reloaded after this configuration file is changed. Once swat has been enabled in - inetd.conf, you can use a browser to - connect to . You - will first have to log on with the system - root account. - - - - Once you have successfully logged on to the main - Samba configuration page, you can - browse the system documentation, or begin by clicking on the + inetd.conf, a web browser may be used to + connect to . At + first login, the system + root account must be used. + + + + Once successfully logging on to the main + Samba configuration page, the + system documentation will be available, or configuration may + begin by clicking on the Globals tab. The Globals section corresponds to the variables that are set in the [global] section of /usr/local/etc/smb.conf. Global Settings - Whether you are using swat or - editing /usr/local/etc/smb.conf - directly, the first directives you are likely to encounter + Whether swat is being used or + /usr/local/etc/smb.conf is being edited + directly, the first directives encountered when configuring Samba are: workgroup NT Domain-Name or Workgroup-Name for the computers that will be accessing this server. netbios name This sets the NetBIOS name by which a Samba server is known. By default it is the same as the first component of the host's DNS name. server string This sets the string that will be displayed with the net view command and some other networking tools that seek to display descriptive text about the server. Security Settings Two of the most important settings in /usr/local/etc/smb.conf are the security model chosen, and the backend password format for client users. The following directives control these options: security The two most common options here are security = share and - security = user. If your clients + security = user. If the clients use usernames that are the same as their usernames on - your &os; machine then you will want to use user level - security. This is the default security policy and it + the &os; machine then user level security should be + used. This is the default security policy and it requires clients to first log on before they can access shared resources. - In share level security, client do not need to log + In share level security, clients do not need to log onto the server with a valid username and password before attempting to connect to a shared resource. This was the default security model for older versions of Samba. passdb backend NIS+ LDAP SQL database Samba has several - different backend authentication models. You can - authenticate clients with LDAP, NIS+, a SQL database, + different backend authentication models. Clients may + be authenticated with LDAP, NIS+, an SQL database, or a modified password file. The default authentication method is smbpasswd, and that is all that will be covered here. Assuming that the default smbpasswd backend is used, the /usr/local/etc/samba/smbpasswd file must be created to allow Samba to - authenticate clients. If you would like to give - your &unix; user accounts access from &windows; clients, use + authenticate clients. To provide + the &unix; user accounts access from &windows; clients, use the following command: &prompt.root; smbpasswd -a username The recommended backend is now tdbsam, and the following command should be used to add user accounts: &prompt.root; pdbedit username Please see the Official Samba HOWTO for additional information about configuration - options. With the basics outlined here, you should have - everything you need to start running - Samba. + options. With the basics outlined here, the minimal required + start running Samba will + be explained. Other documentation should be consulted in + addition to the information here. Starting <application>Samba</application> The net/samba34 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: samba_enable="YES" Or, for fine grain control: nmbd_enable="YES" smbd_enable="YES" This will also configure Samba to automatically start at system boot time. It is possible then to start Samba at any time by typing: &prompt.root; service samba start Starting SAMBA: removing stale tdbs : Starting nmbd. Starting smbd. Please refer to for more information about using rc scripts. Samba actually consists of - three separate daemons. You should see that both the + three separate daemons. Notice that both the nmbd and smbd daemons are started by the - samba script. If you enabled winbind - name resolution services in smb.conf, - then you will also see that the - winbindd daemon is started. + samba script. If winbind, + name resolution services were enabled in + smb.conf, + the winbindd daemon will be + started as well. - You can stop Samba at any time - by typing : + Samba may be stopped at any time + by typing: &prompt.root; service samba stop Samba is a complex software suite with functionality that allows broad integration with µsoft.windows; networks. For more information about functionality beyond the basic installation described here, please see . Tom Hukins Contributed by Clock Synchronization with NTP NTP Overview Over time, a computer's clock is prone to drift. The - Network Time Protocol (NTP) is one way to ensure your clock + Network Time Protocol (NTP) is one way to ensure the clock stays accurate. Many Internet services rely on, or greatly benefit from, computers' clocks being accurate. For example, a web server may receive requests to send a file if it has been modified since a certain time. In a local area network environment, it is essential that computers sharing files from the same file server have synchronized clocks so that file timestamps stay consistent. Services such as &man.cron.8; also rely on an accurate system clock to run commands at the specified times. NTP ntpd - FreeBSD ships with the &man.ntpd.8; &os; ships with the &man.ntpd.8; NTP server which can be used to query other NTP servers to set - the clock on your machine or provide time + the clock on the machine or provide time services to others. Choosing Appropriate NTP Servers NTP choosing servers - In order to synchronize your clock, you will need to find - one or more NTP servers to use. Your network + In order to synchronize the clock, one or more + NTP servers + must be defined. The network administrator or ISP may have set up an NTP server for this purpose—check their documentation to see if this is the case. There is an online - list of publicly accessible NTP servers which you can - use to find an NTP server near to you. Make sure you are - aware of the policy for any servers you choose, and ask for - permission if required. + list of publicly accessible NTP servers which may be + referenced to find an NTP server nearest to the system. + Take care to review the policy for any chosen servers, and ask + for permission if required. Choosing several unconnected NTP servers is a good idea in - case one of the servers you are using becomes unreachable or + case one of the servers being used becomes unreachable or its clock is unreliable. &man.ntpd.8; uses the responses it receives from other servers intelligently—it will favor unreliable servers less than reliable ones. - Configuring Your Machine + Configuring The Machine NTP configuration Basic Configuration ntpdate - If you only wish to synchronize your clock when the - machine boots up, you can use &man.ntpdate.8;. This may be + To synchronize the clock only when the + machine boots up, use &man.ntpdate.8;. This may be appropriate for some desktop machines which are frequently rebooted and only require infrequent synchronization, but most machines should run &man.ntpd.8;. Using &man.ntpdate.8; at boot time is also a good idea for machines that run &man.ntpd.8;. The &man.ntpd.8; program changes the clock gradually, whereas &man.ntpdate.8; sets the clock, no matter how great the difference between a machine's current clock setting and the correct time. To enable &man.ntpdate.8; at boot time, add ntpdate_enable="YES" to - /etc/rc.conf. You will also need to - specify all servers you wish to synchronize with and any + /etc/rc.conf. Also + specify all synchronization servers and any flags to be passed to &man.ntpdate.8; in ntpdate_flags. General Configuration NTP ntp.conf NTP is configured by the /etc/ntp.conf file in the format described in &man.ntp.conf.5;. Here is a simple example: server ntplocal.example.com prefer server timeserver.example.org server ntp2a.example.net driftfile /var/db/ntp.drift The server option specifies which servers are to be used, with one server listed on each line. If a server is specified with the prefer argument, as with ntplocal.example.com, that server is preferred over other servers. A response from a preferred server will be discarded if it differs significantly from other servers' responses, otherwise it will be used without any consideration to other responses. The prefer argument is normally used for NTP servers that are known to be highly accurate, such as those with special time monitoring hardware. The driftfile option specifies which file is used to store the system clock's frequency offset. The &man.ntpd.8; program uses this to automatically compensate for the clock's natural drift, allowing it to maintain a reasonably correct setting even if it is cut off from all external time sources for a period of time. The driftfile option specifies which file is used to store information about previous responses - from the NTP servers you are using. This file contains + from the NTP servers being used. This file contains internal information for NTP. It should not be modified by any other process. Controlling Access to Your Server - By default, your NTP server will be accessible to all + By default, the NTP server will be accessible to all hosts on the Internet. The restrict - option in /etc/ntp.conf allows you to - control which machines can access your server. + option in /etc/ntp.conf + controls which machines can access the server. - If you want to deny all machines from accessing your NTP + To deny all machines from accessing the NTP server, add the following line to /etc/ntp.conf: restrict default ignore - This will also prevent access from your server to - any servers listed in your local configuration. If you - need to synchronise your NTP server with an external NTP - server you should allow the specific server. See the + This will also prevent access from the server to + any servers listed in the local configuration. If there is + a need to synchronise the NTP server with an external NTP + server, allow only that specific server. See the &man.ntp.conf.5; manual for more information. - If you only want to allow machines within your own - network to synchronize their clocks with your server, but + To allow machines within the + network to synchronize their clocks with the server, but ensure they are not allowed to configure the server or used as peers to synchronize against, add restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap instead, where 192.168.1.0 is an IP address on - your network and 255.255.255.0 is your network's + the network and 255.255.255.0 is the network's netmask. - /etc/ntp.conf can contain multiple - restrict options. For more details, see - the Access Control Support subsection of - &man.ntp.conf.5;. + The /etc/ntp.conf file can contain + multiple restrict options. For more + details, see the Access Control Support + subsection of &man.ntp.conf.5;. Running the NTP Server To ensure the NTP server is started at boot time, add the line ntpd_enable="YES" to - /etc/rc.conf. If you wish to pass + /etc/rc.conf. To pass additional flags to &man.ntpd.8;, edit the ntpd_flags parameter in /etc/rc.conf. - To start the server without rebooting your machine, run + To start the server without rebooting the machine, run ntpd being sure to specify any additional parameters from ntpd_flags in /etc/rc.conf. For example: &prompt.root; ntpd -p /var/run/ntpd.pid Using <application>ntpd</application> with a Temporary Internet Connection The &man.ntpd.8; program does not need a permanent connection to the Internet to function properly. However, if - you have a temporary connection that is configured to dial out + there is a temporary connection that is configured to dial out on demand, it is a good idea to prevent NTP traffic from - triggering a dial out or keeping the connection alive. If you - are using user PPP, you can use filter + triggering a dial out or keeping the connection alive. PPP + users can use the filter directives in /etc/ppp/ppp.conf. For example: set filter dial 0 deny udp src eq 123 # Prevent NTP traffic from initiating dial out set filter dial 1 permit 0 0 set filter alive 0 deny udp src eq 123 # Prevent incoming NTP traffic from keeping the connection open set filter alive 1 deny udp dst eq 123 # Prevent outgoing NTP traffic from keeping the connection open set filter alive 2 permit 0/0 0/0 For more details see the PACKET FILTERING section in &man.ppp.8; and the examples in /usr/share/examples/ppp/. Some Internet access providers block low-numbered ports, preventing NTP from functioning since replies never - reach your machine. + reach the machine. Further Information Documentation for the NTP server can be found in /usr/share/doc/ntp/ in HTML format. Tom Rhodes Contributed by Remote Host Logging with <command>syslogd</command> Interacting with system logs is a crucial aspect of both security and system administration. Monitoring the log files of multiple hosts can get very unwieldy when these hosts are distributed across medium or large networks, or when they are parts of various different types of networks. In these cases, configuring remote logging may make the whole process a lot more comfortable. Centralized logging to a specific logging host can reduce some of the administrative burden of log file administration. - Log file aggregation, merging and rotation can be configured in + Log file aggregation, merging and rotation may be configured in one location, using the native tools of &os;, such as &man.syslogd.8; and &man.newsyslog.8;. In the following example configuration, host A, named logserv.example.com, will collect logging information for the local network. Host B, named logclient.example.com will pass logging information to the server system. In live configurations, both hosts require proper forward and reverse DNS or entries in /etc/hosts. Otherwise, data will be rejected by the server. Log Server Configuration Log servers are machines configured to accept logging information from remote hosts. In most cases this is to ease configuration, in other cases it may just be a better administration move. Regardless of reason, there are a few requirements before continuing. A properly configured logging server has met the following minimal requirements: The firewall ruleset allows for UDP to be passed on port 514 on both the client and server; - syslogd has been configured to accept remote messages - from client machines; + syslogd has been configured to + accept remote messages from client machines; - The syslogd server and all client machines must have - valid entries for both forward and reverse - DNS, or be properly configured in - /etc/hosts. + The syslogd server and all client + machines must have valid entries for both forward and + reverse DNS, or be properly configured + in /etc/hosts. To configure the log server, the client must be listed in /etc/syslog.conf, and the logging facility must be specified: +logclient.example.com *.* /var/log/logclient.log More information on various supported and available facilities may be found in the &man.syslog.conf.5; manual page. Once added, all facility messages will be logged to the file specified previously, /var/log/logclient.log. The server machine must also have the following listing placed inside /etc/rc.conf: syslogd_enable="YES" syslogd_flags="-a logclient.example.com -v -v" The first option will enable the syslogd daemon on boot up, and the second option allows data from the specified client to be accepted on this server. The latter part, using , will increase the verbosity of logged messages. This is extremely useful for tweaking facilities as administrators are able to see what type of messages are being logged under which facility. Multiple options may be specified to allow logging from multiple clients. IP addresses and whole netblocks may also be specified, see the &man.syslog.3; manual page for a full list of possible options. Finally, the log file should be created. The method used does not matter, but &man.touch.1; works great for situations such as this: - &prompt.root; touch /var/log/logclient.log + &prompt.root; touch + /var/log/logclient.log At this point, the syslogd daemon should be restarted and verified: - &prompt.root; service syslogd restart -&prompt.root; pgrep syslog + &prompt.root; service syslogd restart +&prompt.root; pgrep syslog If a PID is returned, the server has been restarted successfully, and client configuration may begin. If the server has not restarted, consult the /var/log/messages log for any output. Log Client Configuration A logging client is a machine which sends log information to a logging server in addition to keeping local copies. Similar to log servers, clients must also meet a few minimum requirements: &man.syslogd.8; must be configured to send messages of specific types to a log server, which must accept them; The firewall must allow UDP packets through on port 514; Both forward and reverse DNS must be configured or have proper entries in the /etc/hosts. Client configuration is a bit more relaxed when compared to that of the servers. The client machine must have the following listing placed inside /etc/rc.conf: syslogd_enable="YES" syslogd_flags="-s -v -v" As before, these entries will enable the syslogd daemon on boot up, and increases the verbosity of logged messages. The option prevents logs from being accepted by this client from other hosts. Facilities describe the system part for which a message is generated. For an example, ftp and ipfw are both facilities. When log messages are generated for those two services, they will normally include those two utilities in any log messages. Facilities are accompanied with a priority or level, which is used to mark how important a log message is. The most common will be the warning and info. Please refer to the &man.syslog.3; manual page for a full list of available facilities and priorities. The logging server must be defined in the client's /etc/syslog.conf. In this instance, the @ symbol is used to send logging data to a remote server and would look similar to the following entry: *.* @logserv.example.com Once added, syslogd must be restarted for the changes to take effect: - &prompt.root; service syslogd restart + &prompt.root; service syslogd restart To test that log messages are being sent across the network, use &man.logger.1; on the client to send a message to syslogd: - &prompt.root; logger "Test message from logclient" + &prompt.root; logger + "Test message from logclient" This message should now exist both in /var/log/messages on the client, and /var/log/logclient.log on the log server. Debugging Log Servers In certain cases, debugging may be required if messages are not being received on the log server. There are several reasons this may occur; however, the most common two are network connection issues and DNS issues. To test these cases, ensure both hosts are able to reach one another using the hostname specified in /etc/rc.conf. If this appears to be working properly, an alternation to the syslogd_flags option in /etc/rc.conf will be required. In the following example, /var/log/logclient.log is empty, and the /var/log/messages files indicate no reason for the failure. To increase debugging output, change the syslogd_flags option to look like the following example, and issue a restart: syslogd_flags="-d -a logclien.example.com -v -v" - &prompt.root; service syslogd restart + &prompt.root; service syslogd restart Debugging data similar to the following will flash on the screen immediately after the restart: logmsg: pri 56, flags 4, from logserv.example.com, msg syslogd: restart syslogd: restarted logmsg: pri 6, flags 4, from logserv.example.com, msg syslogd: kernel boot file is /boot/kernel/kernel Logging to FILE /var/log/messages syslogd: kernel boot file is /boot/kernel/kernel cvthname(192.168.1.10) validate: dgram from IP 192.168.1.10, port 514, name logclient.example.com; rejected in rule 0 due to name mismatch. It appears obvious the messages are being rejected due to a name mismatch. After reviewing the configuration bit by bit, it appears a typo in the following /etc/rc.conf line has an issue: syslogd_flags="-d -a logclien.example.com -v -v" The line should contain logclient, not logclien. After the proper alterations are made, a restart is issued with expected results: - &prompt.root; service syslogd restart + &prompt.root; service syslogd restart logmsg: pri 56, flags 4, from logserv.example.com, msg syslogd: restart syslogd: restarted logmsg: pri 6, flags 4, from logserv.example.com, msg syslogd: kernel boot file is /boot/kernel/kernel syslogd: kernel boot file is /boot/kernel/kernel logmsg: pri 166, flags 17, from logserv.example.com, msg Dec 10 20:55:02 <syslog.err> logserv.example.com syslogd: exiting on signal 2 cvthname(192.168.1.10) validate: dgram from IP 192.168.1.10, port 514, name logclient.example.com; accepted in rule 0. logmsg: pri 15, flags 0, from logclient.example.com, msg Dec 11 02:01:28 trhodes: Test message 2 Logging to FILE /var/log/logclient.log Logging to FILE /var/log/messages At this point, the messages are being properly received and placed in the correct file. Security Considerations As with any network service, security requirements should be considered before implementing this configuration. At times, log files may contain sensitive data about services enabled on the local host, user accounts, and configuration data. Network data sent from the client to the server will not be encrypted nor password protected. If a need for encryption exists, it might be possible to use security/stunnel, which will transmit data over an encrypted tunnel. Local security is also an issue. Log files are not encrypted during use or after log rotation. Local users may access these files to gain additional insight on system configuration. In those cases, setting proper permissions on these files will be critical. The &man.newsyslog.8; utility supports setting permissions on newly created and rotated log files. Setting log files to mode 600 should prevent any unwanted snooping by local users. diff --git a/en_US.ISO8859-1/books/handbook/ports/chapter.xml b/en_US.ISO8859-1/books/handbook/ports/chapter.xml index f00a54b828..39d26ffa0a 100644 --- a/en_US.ISO8859-1/books/handbook/ports/chapter.xml +++ b/en_US.ISO8859-1/books/handbook/ports/chapter.xml @@ -1,1930 +1,1928 @@ Installing Applications: Packages and Ports Synopsis ports packages &os; is bundled with a rich collection of system tools as part of the base system. However, there is only so much one can do before needing to install an additional third-party application to get real work done. &os; provides two complementary technologies for installing third-party software: the &os; Ports Collection (for installing from source), and packages (for installing from pre-built binaries). Either method may be used to install software from local media or from the network. After reading this chapter, you will know how to: Install third-party binary software packages. Build third-party software from source by using the Ports Collection. Remove previously installed packages or ports. Override the default values used by the Ports Collection. Find the appropriate software package. Upgrade installed software. Overview of Software Installation The typical steps for installing third-party software on a &unix; system include: Download the software, which might be distributed in source code format, or as a binary. Unpack the software from its distribution format (typically a tarball compressed with &man.compress.1;, &man.gzip.1;, or &man.bzip2.1;). Locate the documentation in INSTALL, README or some file in a doc/ subdirectory and read up on how to install the software. If the software was distributed in source format, compile it. This may involve editing a Makefile, or running a configure script, and other work. Test and install the software. If you are installing a software package that was not deliberately ported to &os; you may even have to go in and edit the code to make it work properly. &os; provides two technologies which perform these steps for you. At the time of writing, over &os.numports; third-party applications are available. A &os; package contains pre-compiled copies of all the commands for an application, as well as any configuration files and documentation. A package can be manipulated with &os; package management commands, such as &man.pkg.add.1;, &man.pkg.delete.1;, and &man.pkg.info.1;. A &os; port is a collection of files designed to automate the process of compiling an application from source code. The files that comprise a port contain all the necessary information to automatically download, extract, patch, compile, and install the application. The ports system can also be used to generate packages which can be manipulated with the &os; package management commands. Both packages and ports understand dependencies. If &man.pkg.add.1; or the Ports Collection is used to install an application and a dependent library is not already installed, the library will automatically be installed first. While the two technologies are quite similar, packages and ports each have their own strengths. Select the technology that meets your requirements for installing a particular application. Package Benefits A compressed package tarball is typically smaller than the compressed tarball containing the source code for the application. Packages do not require compilation time. For large applications, such as Mozilla, KDE, or GNOME this can be important, on a slow system. Packages do not require any understanding of the process involved in compiling software on &os;. Ports Benefits Packages are normally compiled with conservative options because they have to run on the maximum number of systems. By compiling from the port, one can change the compilation options. Some applications have compile-time options relating to which features are installed. For example, Apache can be configured with a wide variety of different built-in options. In some cases, multiple packages will exist for the same application to specify certain settings. For example, Ghostscript is available as a ghostscript package and a ghostscript-nox11 package, depending on whether or not Xorg is installed. Creating multiple packages rapidly becomes impossible if an application has more than one or two different compile-time options. The licensing conditions of some software forbid binary distribution. These must be distributed as source code which must be compiled by the end-user. Some people do not trust binary distributions or prefer to read through source code in order to look for potential problems. If you have local patches, you will need the source in order to apply them. To keep track of updated ports, subscribe to the &a.ports; and the &a.ports-bugs;. Before installing any application, check for security issues related to the application or install ports-mgmt/portaudit. Once installed, type portaudit -F -a to check all installed applications for known vulnerabilities. The remainder of this chapter explains how to use packages and ports to install and manage third-party software on &os;. Finding Software &os;'s list of available applications is growing all the time. There are a number of ways to find software to install: The &os; web site maintains an up-to-date searchable list of all the available applications, at http://www.FreeBSD.org/ports/. The ports can be searched by application name or by software category. FreshPorts Dan Langille maintains FreshPorts which provides a comprehensive search utility and also tracks changes to the applications in the Ports Collection. Registered users can create a customized watch list in order to receive an automated email when their watched ports are updated. Freecode If you do not know the name of the application you want, try using a site like Freecode () to find an application, then check back at the &os; site to see if the application has been ported yet. To find out which category a port is in, type whereis file, where file is the program to be installed: &prompt.root; whereis lsof lsof: /usr/ports/sysutils/lsof Alternately, an &man.echo.1; statement can be used: &prompt.root; echo /usr/ports/*/*lsof* /usr/ports/sysutils/lsof Note that this will return any matched files downloaded into the /usr/ports/distfiles directory. Another way to find software is by using the Ports Collection's built-in search mechanism. To use the search feature, cd to /usr/ports then run make search name=program-name where program-name is the name of the software. For example, to search for lsof: &prompt.root; cd /usr/ports &prompt.root; make search name=lsof Port: lsof-4.56.4 Path: /usr/ports/sysutils/lsof Info: Lists information about open files (similar to fstat(1)) Maint: obrien@FreeBSD.org Index: sysutils B-deps: R-deps: make search searches through a file of index information. If a message indicates the INDEX is required, run make fetchindex to download the current index file. With the INDEX present, make search will be able to perform the requested search. The Path: line indicates where to find the port. To receive less information, use the quicksearch feature: &prompt.root; cd /usr/ports &prompt.root; make quicksearch name=lsof Port: lsof-4.87.a,7 Path: /usr/ports/sysutils/lsof Info: Lists information about open files (similar to fstat(1)) For more in-depth searching, use make search key=string or make quicksearch key=string, where string is some text to search for. The text can be in comments, descriptions, or dependencies in order to find ports which relate to a particular subject when the name of the program is unknown. When using (search and quicksearch), the search string is case-insensitive. Searching for LSOF will yield the same results as searching for lsof. Chern Lee Contributed by Using Binary Packages - There are several different tools used to manage packages on - &os;: - - - - The sysinstall utility can be invoked - on a running system to install, delete, and list available - and installed packages. For more information, see - . - - - - The package management command line tools, which are - the subject of the rest of this section. - - + At the present time, &os; is transitioning toward a new + method of package management. Users of the latest releases + may wish to investigate the benefits of using + PKGng to manage third + party software on &os;. For those not yet migrated to the + pkgng tool, the tools discussed + here may be used for managing the package database. For + simplicity, the sysinstall utility is + also available post-install for package management. + + All package installation files are stored in the + package database directory, + /var/db/pkg. Installing a Package packages installing pkg_add Use &man.pkg.add.1; to install a &os; binary package from a local file or from a server on the network. Downloading a Package Manually and Installing It Locally &prompt.root; ftp -a ftp2.FreeBSD.org Connected to ftp2.FreeBSD.org. 220 ftp2.FreeBSD.org FTP server (Version 6.00LS) ready. 331 Guest login ok, send your email address as password. 230- 230- This machine is in Vienna, VA, USA, hosted by Verio. 230- Questions? E-mail freebsd@vienna.verio.net. 230- 230- 230 Guest login ok, access restrictions apply. Remote system type is UNIX. Using binary mode to transfer files. ftp> cd /pub/FreeBSD/ports/packages/sysutils/ 250 CWD command successful. ftp> get lsof-4.56.4.tgz local: lsof-4.56.4.tgz remote: lsof-4.56.4.tgz 200 PORT command successful. 150 Opening BINARY mode data connection for 'lsof-4.56.4.tgz' (92375 bytes). 100% |**************************************************| 92375 00:00 ETA 226 Transfer complete. 92375 bytes received in 5.60 seconds (16.11 KB/s) ftp> exit &prompt.root; pkg_add lsof-4.56.4.tgz If you do not have a source of local packages, such as a &os; CD-ROM set, include with &man.pkg.add.1;. This automatically determines the correct object format and release, and then fetches and installs the package from an FTP site without any further user intervention. pkg_add &prompt.root; pkg_add -r lsof To specify an alternative &os; FTP mirror, specify the mirror in the PACKAGESITE environment variable. &man.pkg.add.1; uses &man.fetch.3; to download files, which uses various environment variables, including FTP_PASSIVE_MODE, FTP_PROXY, and FTP_PASSWORD. You may need to set one or more of these if you are behind a firewall, or need to use an FTP/HTTP proxy. See &man.fetch.3; for the complete list of variables. Note that in the example above lsof is used instead of lsof-4.56.4. When the remote fetching feature is used, the version number of the package must be removed. &man.pkg.add.1; will automatically download the latest version of the application if you are using &os.current; or &os.stable;. If you run a -RELEASE version, it instead installs the version of the package that was built with that release. It is possible to change this behavior by overriding PACKAGESITE. For example, on a &os; 8.1-RELEASE system, by default &man.pkg.add.1; will try to fetch packages from ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8.1-release/Latest/. To force &man.pkg.add.1; to download &os; 8-STABLE packages, set PACKAGESITE to ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8-stable/Latest/. Package files are distributed in .tgz and .tbz formats. Packages are available from , or the /packages directory of the &os; DVD distribution. The layout of the packages directory is similar to that of the /usr/ports tree. Each category has its own directory, and every package can be found within the All directory. Managing Packages packages managing &man.pkg.info.1; can be used to list and describe installed packages: pkg_info &prompt.root; pkg_info colordiff-1.0.13 A tool to colorize diff output docbook-1.2 Meta-port for the different versions of the DocBook DTD ... &man.pkg.version.1; summarizes the versions of all installed packages and compares the package version to the current version found in the ports tree. pkg_version &prompt.root; pkg_version colordiff = docbook = ... The symbols in the second column indicate the relative age of the installed version and the version available in the local ports tree. Symbol Meaning = The version of the installed package matches the one in the local ports tree. < The version of the installed package is older than the one in the local ports tree. > The version of the installed package is newer than the one in the local ports tree, meaning that the local ports tree is probably out of date. ? The installed package cannot be found in the ports index. This can happen when an installed port is removed from the Ports Collection or is renamed. * There are multiple versions of the package. ! The installed package exists in the index but for some reason, pkg_version was unable to compare the version number of the installed package with the corresponding entry in the index. Deleting a Package pkg_delete packages deleting To remove a previously installed software package, use &man.pkg.delete.1;: &prompt.root; pkg_delete xchat-1.7.1 Note that &man.pkg.delete.1; requires the full package name and number; the above command would not work if xchat was given instead of xchat-1.7.1. Use &man.pkg.version.1; to find the version of the installed package, or use a wildcard: &prompt.root; pkg_delete xchat\* in this case, all packages whose names start with xchat will be deleted. - - - Miscellaneous - - All package information, including the file list and - descriptions of each installed package is stored within the - /var/db/pkg directory. - Using <application>pkgng</application> for Binary Package Management pkgng is an improved replacement for the traditional &os; package management tools, offering many features that make dealing with binary packages faster and easier. The first release of pkgng was in August, 2012. pkgng is not a replacement for port management tools like ports-mgmt/portmaster or ports-mgmt/portupgrade. While ports-mgmt/portmaster and ports-mgmt/portupgrade can install third-party software from both binary packages and the Ports Collection, pkgng installs only binary packages. Getting Started with <application>pkgng</application> &os; 9.1 and later includes a "bootstrap" utility for pkgng. The bootstrap utility will download and install pkgng. To bootstrap the system, run: &prompt.root; /usr/sbin/pkg For earlier &os; versions, pkgng must be installed from the Ports Collection, or as a binary package. To install the pkgng port, run: &prompt.root; cd /usr/ports/ports-mgmt/pkg &prompt.root; make &prompt.root; make install clean To install the binary package, run: &prompt.root; pkg_add -r pkg Existing &os; installations require conversion of the pkg_install package database to the new format. To convert the package database, run: &prompt.root; pkg2ng This step is not required for new installations that do not have third-party software installed. This step is not reversible. Once the package database has been converted to the pkgng format, the pkg_install tools should not be used. The package database conversion may emit errors as the contents are converted to the new version. Generally, these errors can be safely ignored, however a list of third-party software that was not successfully converted will be listed after pkg2ng has finished. These must be fixed by hand. To ensure the &os; Ports Collection registers new software with pkgng, and not pkg_install, &os; versions earlier than 10.X require this line in /etc/make.conf: WITH_PKGNG= yes Configuring the <application>pkgng</application> Environment The pkgng package management system uses a package repository for most operations. The default package repository location is defined in /usr/local/etc/pkg.conf or the PACKAGESITE environment variable, which overrides the configuration file. Additional pkgng configuration options are described in pkg.conf(5). Basic <application>pkgng</application> Operations Usage information for pkgng is available in the pkg(8) manual page, or by running pkg without additional arguments. Each pkgng command argument is documented in a command-specific manual page. To read the manual page for pkg install, for example, run either: &prompt.root; pkg help install &prompt.root; man pkg-install Obtaining Information About Installed Packages with <application>pkgng</application> Information about the packages installed on a system can be viewed by running pkg info. Similar to &man.pkg.info.1;, the package version and description for all packages will be listed. Information about a specific package is available by running: &prompt.root; pkg info packagename For example, to see which version of pkgng is installed on the system, run: &prompt.root; pkg info pkg pkg-1.0.2 New generation package manager Installing and Removing Packages with <application>pkgng</application> In general, most &os; users will install binary packages by running: &prompt.root; pkg install packagename pkg install uses repository data, as mentioned in . Conversely, pkg-add(8) does not use repository data, nor does it use the defined PACKAGESITE, so dependencies may not be properly tracked, and missing dependencies will not be fetched from a remote source. This section covers usage of pkg install. For information on usage of pkg add, see pkg-add(8). Additional binary packages can be installed with pkg install. For example, to install curl: &prompt.root; pkg install curl Updating repository catalogue Repository catalogue is up-to-date, no need to fetch fresh copy The following packages will be installed: Installing ca_root_nss: 3.13.5 Installing curl: 7.24.0 The installation will require 4 MB more space 1 MB to be downloaded Proceed with installing packages [y/N]: y ca_root_nss-3.13.5.txz 100% 255KB 255.1KB/s 255.1KB/s 00:00 curl-7.24.0.txz 100% 1108KB 1.1MB/s 1.1MB/s 00:00 Checking integrity... done Installing ca_root_nss-3.13.5... done Installing curl-7.24.0... done The new package and any additional packages that were installed as dependencies can be seen in the installed packages list: &prompt.root; pkg info ca_root_nss-3.13.5 The root certificate bundle from the Mozilla Project curl-7.24.0 Non-interactive tool to get files from FTP, GOPHER, HTTP(S) servers pkg-1.0.2 New generation package manager Packages that are no longer needed can be removed with pkg delete. For example, if it turns out that curl is not needed after all: &prompt.root; pkg delete curl The following packages will be deleted: curl-7.24.0_1 The deletion will free 3 MB Proceed with deleting packages [y/N]: y Deleting curl-7.24.0_1... done Upgrading Installed Packages with <application>pkgng</application> Packages that are outdated can be found with pkg version. If a local ports tree does not exist, pkg-version(8) will use the remote repository catalogue, otherwise the local ports tree will be used to identify package versions. Packages can be upgraded to newer versions with pkgng. Suppose a new version of curl has been released. The local package can be upgraded to the new version: &prompt.root; pkg upgrade Updating repository catalogue repo.txz 100% 297KB 296.5KB/s 296.5KB/s 00:00 The following packages will be upgraded: Upgrading curl: 7.24.0 -> 7.24.0_1 1 MB to be downloaded Proceed with upgrading packages [y/N]: y curl-7.24.0_1.txz 100% 1108KB 1.1MB/s 1.1MB/s 00:00 Checking integrity... done Upgrading curl from 7.24.0 to 7.24.0_1... done Auditing Installed Packages with <application>pkgng</application> Occasionally, software vulnerabilities may be discovered in software within the Ports Collection. pkgng includes built-in auditing, similar to the ports-mgmt/portaudit package. To audit the software installed on the system, run: &prompt.root; pkg audit -F Advanced <application>pkgng</application> Operations Automatically Removing Leaf Dependencies with <application>pkgng</application> Removing a package may leave behind unnecessary dependencies, like security/ca_root_nss in the example above. Such packages are still installed, but nothing depends on them any more. Unneeded packages that were installed as dependencies can be automatically detected and removed: &prompt.root; pkg autoremove Packages to be autoremoved: ca_root_nss-3.13.5 The autoremoval will free 723 kB Proceed with autoremoval of packages [y/N]: y Deinstalling ca_root_nss-3.13.5... done Backing Up the <application>pkgng</application> Package Database Unlike the traditional package management system, pkgng includes its own package database backup mechanism. To manually back up the package database contents, run: &prompt.root; pkg backup -d pkgng.db Replace the file name pkgng.db to a suitable file name. Additionally, pkgng includes a &man.periodic.8; script to automatically back up the package database daily if daily_backup_pkgng_enable is set to YES in &man.periodic.conf.5;. To prevent the pkg_install periodic script from also backing up the package database, set daily_backup_pkgdb_enable to NO in &man.periodic.conf.5;. To restore the contents of a previous package database backup, run: &prompt.root; pkg backup -r /path/to/pkgng.db Removing Stale <application>pkgng</application> Packages By default, pkgng stores binary packages in a cache directory as defined by PKG_CACHEDIR in pkg.conf(5). When upgrading packages with pkg upgrade, old versions of the upgraded packages are not automatically removed. To remove the outdated binary packages, run: &prompt.root; pkg clean Modifying <application>pkgng</application> Package Metadata Historically, software within the &os; Ports Collection can undergo major version number changes. Unlike pkg_install, pkgng has a built-in command to update package origins. For example, if lang/php5 was originally at version 5.3, but has been renamed to lang/php53 for the inclusion of version 5.4, pkg_install would require the use of additional software such as ports-mgmt/portmaster to update the package database, reflecting from which port the installation originated. Unlike the ports-mgmt/portmaster and ports-mgmt/portupgrade ports, the order in which the new and old versions are listed differ. For pkgng, the syntax is: &prompt.root; pkg set -o category/oldport:category/newport For example, to change the package origin for the above example, run: &prompt.root; pkg set -o lang/php5:lang/php53 As another example, to update lang/ruby18 to lang/ruby19, run: &prompt.root; pkg set -o lang/ruby18:lang/ruby19 As a final example, to change the origin of the libglut shared libraries from graphics/libglut to graphics/freeglut, run: &prompt.root; pkg set -o graphics/libglut:graphics/freeglut When changing package origins, in most cases it is important to reinstall packages that are dependent on the package that has had the origin changed. To force a reinstallation of dependent packages, run: &prompt.root; pkg install -Rf graphics/freeglut Using the Ports Collection This section provides basic instructions on using the Ports Collection to install or remove software. The detailed description of available make targets and environment variables is available in &man.ports.7;. As of mid 2012, the &os; Ports Project has migrated revision control systems from CVS to Subversion. The preferred method for obtaining and maintaining the ports tree is Portsnap. Users requiring local customization of ports (that is, maintaining additional local patches) will probably prefer to use Subversion directly. The CVSup service was phased out as of February 28, 2013. Obtaining the Ports Collection The Ports Collection is a set of Makefiles, patches, and description files stored in /usr/ports. This set of files is used to compile and install applications on &os;. The instructions below show several methods of obtaining the Ports Collection if it was not installed during initial &os; setup. Portsnap Method Portsnap is a fast and user-friendly tool for retrieving the Ports Collection, the preferred choice for most users. See Using Portsnap for a detailed description of Portsnap. Download a compressed snapshot of the Ports Collection into /var/db/portsnap. &prompt.root; portsnap fetch When running Portsnap for the first time, extract the snapshot into /usr/ports: &prompt.root; portsnap extract After the first use of Portsnap has been completed as shown above, /usr/ports can be updated with: &prompt.root; portsnap fetch &prompt.root; portsnap update Subversion Method If more control over the ports tree is needed (for example, for maintaining local changes), Subversion can be used to obtain the Ports Collection. Refer to the Subversion Primer for a detailed description of Subversion. Subversion must be installed before it can be used to check out the ports tree. If a copy of the ports tree is already present, install Subversion like this: &prompt.root; cd /usr/ports/devel/subversion &prompt.root; make install clean If the ports tree is not available, Subversion can be installed as a package: &prompt.root; pkg_add -r subversion If pkgng is being used to manage packages, Subversion can be installed with it instead: &prompt.root; pkg install subversion Check out a copy of the ports tree. Use a specific Subversion mirror close to your geographic location instead of svn0.us-east.FreeBSD.org in the command below for better performance. Committers should read the Subversion Primer first to be sure the correct protocol is chosen. &prompt.root; svn checkout https://svn0.us-east.FreeBSD.org/ports/head /usr/ports To update /usr/ports after the initial Subversion checkout: &prompt.root; svn update /usr/ports Sysinstall Method This method involves using sysinstall to install the Ports Collection from the installation media. Note that the old copy of Ports Collection from the date of the release will be installed. If you have Internet access, you should always use one of the methods mentioned above. As root, run sysinstall as shown below: &prompt.root; sysinstall Scroll down and select Configure, press Enter. Scroll down and select Distributions, press Enter. Scroll down to ports, press Space. Scroll up to Exit, press Enter. Select your desired installation media, such as CDROM, FTP, and so on. Scroll up to Exit and press Enter. Press X to exit sysinstall. Migrating from <application>CVSup</application>/<application>csup</application> to <application>portsnap</application> By February 28, 2013, the ports tree will no longer be exported to CVS and therefore CVSup and csup will no longer provide updates for the ports tree. Migration to Portsnap The migration will require about 1 GB of disk space on /usr, plus Portsnap requires about 150 MB disk space on /var. Disable any automated ports updates you may use, such as a &man.cron.8; job calling CVSup or csup. Move the existing ports tree to a temporary location: &prompt.root; mv /usr/ports /usr/ports.old Fetch the new ports tree with Portsnap and extract it to /usr/ports: &prompt.root; portsnap fetch extract Move distfiles and saved packages to the new ports tree: &prompt.root; mv /usr/ports.old/distfiles /usr/ports &prompt.root; mv /usr/ports.old/packages /usr/ports Delete the old ports tree: &prompt.root; rm -rf /usr/ports.old If CVSup was used before, it can now be uninstalled: &prompt.root; pkg_delete -r -v cvsup-without-gui-\* Users of pkgng can use the following command: &prompt.root; pkg delete cvsup-without-gui See Using Portsnap for a detailed description of Portsnap and how to update the ports tree with Portsnap. Installing Ports ports installing A port skeleton is a set of files that tell &os; system how to compile and install a program. Each port skeleton includes: Makefile: The Makefile contains statements that specify how the application should be compiled and where its components should be installed. distinfo: This file contains information about the files that must be downloaded to build the port, and their checksums (using &man.sha256.1;), to verify that files have not been corrupted during the download. files/: This directory contains any patches needed for the program to compile and install on &os;. This directory may also contain other files used to build the port. pkg-descr: This file provides a more detailed description of the program. pkg-plist: This is a list of all the files that will be installed by the port. It also tells the ports system what files to remove upon deinstallation. Some ports include other files, such as pkg-message. The ports system uses these files to handle special situations. If you want more details on these files, and on ports in general, refer to the &os; Porter's Handbook. The port does not include the actual source code, also known as a distfile. Source code is distributed in whatever manner the software author desires. The two methods for installing a &os; port are described below. You must be logged in as root to install ports. Before compiling any port, be sure to have an up-to-date Ports Collection and check for security issues related to your port. If ports-mgmt/portaudit is installed, run portaudit -F before installing a new port, to fetch the current vulnerabilities database. A security audit and an update of the database will be performed during the daily security system check. For more information read the &man.portaudit.1; and &man.periodic.8; manual pages. Using the Ports Collection assumes a working Internet connection. Otherwise, manually obtain and place a copy of the distfile into /usr/ports/distfiles. To begin, change to the directory of the port to be installed: &prompt.root; cd /usr/ports/sysutils/lsof To compile, or build, the port, type make at the prompt. You should see messages similar to the ones in this example: &prompt.root; make >> lsof_4.57D.freebsd.tar.gz doesn't seem to exist in /usr/ports/distfiles/. >> Attempting to fetch from ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/. ===> Extracting for lsof-4.57 ... [extraction output snipped] ... >> Checksum OK for lsof_4.57D.freebsd.tar.gz. ===> Patching for lsof-4.57 ===> Applying FreeBSD patches for lsof-4.57 ===> Configuring for lsof-4.57 ... [configure output snipped] ... ===> Building for lsof-4.57 ... [compilation output snipped] ... &prompt.root; Once the compile is complete, you are returned to the prompt. The next step is to install the port using make install: &prompt.root; make install ===> Installing for lsof-4.57 ... [installation output snipped] ... ===> Generating temporary packing list ===> Compressing manual pages for lsof-4.57 ===> Registering installation for lsof-4.57 ===> SECURITY NOTE: This port has installed the following binaries which execute with increased privileges. &prompt.root; Once you are returned to the prompt, you should be able to run the installed application. Since lsof is a program that runs with increased privileges, a security warning is shown. During the building and installation of ports, take heed of any other warnings that may appear. It is a good idea to delete the working subdirectory, which contains all the temporary files used during compilation. Doing so saves disk space and minimizes the chance of problems later when upgrading to the newer version of the port. &prompt.root; make clean ===> Cleaning for lsof-4.57 &prompt.root; You can save two extra steps by just running make install clean instead of make, make install and make clean as three separate steps. Using only make install means there will potentially be many waiting periods between user interaction as the default behaviour is to prompt the user for options. To avoid this when there are many dependencies, first run make config-recursive to do the configuration in one batch. Then run make install [clean] afterwards. When using config-recursive, the list of ports to configure are gathered by the all-depends-list &man.make.1; target. It is often recommended to run make config-recursive until all dependent ports options have been defined, and ports options &man.dialog.1; screens no longer appear, to be certain all ports options have been configured as intended. Some shells keep a cache of the commands that are available in the directories listed in the PATH environment variable, to speed up lookup operations for the executable file of these commands. If you are using tcsh, you might have to type rehash so that a newly installed command can be used without specifying its full path. Use hash -r instead for the sh shell. Refer to the documentation for the shell for more information. Some third-party DVD products such as the &os; Toolkit from the &os; Mall contain distfiles. They can be used with the Ports Collection. Mount the DVD on /cdrom. If you use a different mount point, set CD_MOUNTPTS make variable. The needed distfiles will be automatically used if they are present on the disk. The licenses of a few ports do not allow their inclusion on the DVD. This could be because a registration form needs to be filled out before downloading or redistribution is not allowed. If you wish to install a port not included on the DVD, you will need to be connected to the Internet. The ports system uses &man.fetch.1; to download the files, which honors various environment variables, including FTP_PASSIVE_MODE, FTP_PROXY, and FTP_PASSWORD. You may need to set one or more of these if you are behind a firewall, or need to use an FTP/HTTP proxy. See &man.fetch.3; for the complete list. For users which cannot be connected all the time, the make fetch option is provided. Run this command within /usr/ports and the required files will be downloaded. This command also works in the lower level categories, such as /usr/ports/net. Note that if a port depends on libraries or other ports, this will not fetch the distfiles of ports from another category. Use make fetch-recursive to fetch all the dependencies of a port. You can build all the ports in a category or as a whole by running make in the top level directory. This is dangerous, however, as some ports cannot co-exist. In other cases, some ports can install two different files with the same filename. In some rare cases, users may need to acquire the tarballs from a site other than the default MASTER_SITES. You can override the MASTER_SITES option with the following command: &prompt.root; cd /usr/ports/directory &prompt.root; make MASTER_SITE_OVERRIDE= \ ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/ fetch In this example, MASTER_SITES is changed to ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/. Some ports provide build options which can be used to enable/disable parts of the application which are unneeded, provide security options, or allow for other customizations. Examples include www/firefox, security/gpgme, and mail/sylpheed-claws. A menu will be displayed at the beginning of a port compile when compile options are available. Overriding the Default Ports Directories The WRKDIRPREFIX and PREFIX variables can override the default working and target directories. For example: &prompt.root; make WRKDIRPREFIX=/usr/home/example/ports install will compile the port in /usr/home/example/ports and install everything under /usr/local. &prompt.root; make PREFIX=/usr/home/example/local install will compile the port in /usr/ports and install it in /usr/home/example/local. And &prompt.root; make WRKDIRPREFIX=../ports PREFIX=../local install will combine the two. Alternatively, these can be set as environmental variables. Refer to the manual page for your shell for instructions on how to set an environmental variable. Reconfiguring Ports Certain ports provide an ncurses-based menu containing build options. There are several ways to revisit this menu in order to add, remove, or change these options after a port has been built. One method is to cd into the directory containing the port and type make config. Another option is to use make showconfig. Another option is to execute make rmconfig which will remove all selected options and allow you to start over. All of these options, and others, are explained in great detail in the manual page for &man.ports.7;. Removing Installed Ports ports removing Installed ports and packages are uninstalled using the &man.pkg.delete.1; command: &prompt.root; pkg_delete lsof-4.57 Upgrading Ports ports upgrading First, list outdated ports that have a newer version available in the Ports Collection with the &man.pkg.version.1; command: &prompt.root; pkg_version -v Read <filename>/usr/ports/UPDATING</filename> Once you have updated your Ports Collection, before attempting a port upgrade, you should check /usr/ports/UPDATING. This file describes various issues and additional steps users may encounter and need to perform when updating a port, including such things as file format changes, changes in locations of configuration files, or other such incompatibilities with previous versions. If UPDATING contradicts something you read here, UPDATING takes precedence. Upgrading Ports Using Portupgrade portupgrade The portupgrade utility is designed to easily upgrade installed ports. It is available from the ports-mgmt/portupgrade port. Install it like any other port, using make install clean: &prompt.root; cd /usr/ports/ports-mgmt/portupgrade &prompt.root; make install clean Scan the list of installed ports using pkgdb -F and fix all the inconsistencies it reports. It is a good idea to do this regularly, before every upgrade. Use portupgrade -a to upgrade all the outdated ports installed on the system. Include to be asked for confirmation of every individual upgrade. &prompt.root; portupgrade -ai To upgrade only a specified application instead of all available ports, use portupgrade pkgname. Include to first upgrade all the ports required by the given application. &prompt.root; portupgrade -R firefox To use packages instead of ports, include the flag. With this option, portupgrade searches the local directories listed in PKG_PATH, then fetches packages from a remote site if not found locally. If packages can not be found locally or fetched remotely, portupgrade will use ports. To avoid using ports, specify . &prompt.root; portupgrade -PP gnome2 To just fetch distfiles (or packages, if is specified) without building or installing anything, use . For further information see &man.portupgrade.1;. Upgrading Ports Using <application>portmaster</application> portmaster ports-mgmt/portmaster is another utility for upgrading installed ports. portmaster was designed to use the tools found in the base system without depending upon other ports. It uses the information in /var/db/pkg/ to determine which ports to upgrade. To install the port: &prompt.root; cd /usr/ports/ports-mgmt/portmaster &prompt.root; make install clean Portmaster groups ports into four categories: Root ports: no dependencies and is not depended on by other ports Trunk ports: no dependencies, but other ports depend upon it Branch ports: have dependencies and are depended upon by other ports Leaf ports: have dependencies but are not depended upon by other ports To list all installed software and search for updates, use : &prompt.root; portmaster -L ===>>> Root ports (No dependencies, not depended on) ===>>> ispell-3.2.06_18 ===>>> screen-4.0.3 ===>>> New version available: screen-4.0.3_1 ===>>> tcpflow-0.21_1 ===>>> 7 root ports ... ===>>> Branch ports (Have dependencies, are depended on) ===>>> apache22-2.2.3 ===>>> New version available: apache22-2.2.8 ... ===>>> Leaf ports (Have dependencies, not depended on) ===>>> automake-1.9.6_2 ===>>> bash-3.1.17 ===>>> New version available: bash-3.2.33 ... ===>>> 32 leaf ports ===>>> 137 total installed ports ===>>> 83 have new versions available All the installed ports can be upgraded using this command: &prompt.root; portmaster -a By default, portmaster will make a backup package before deleting the existing port. If the installation of the new version is successful, portmaster will delete the backup. Using will instruct portmaster not to automatically delete the backup. Adding will start portmaster in interactive mode, prompting for confirmation before upgrading each port. If you encounter errors during the upgrade process, use to upgrade/rebuild all ports: &prompt.root; portmaster -af You can also use portmaster to install new ports on the system, upgrading all dependencies before building and installing the new port: &prompt.root; portmaster shells/bash Refer to &man.portmaster.8; for more information. Ports and Disk Space ports disk-space Using the Ports Collection will use up disk space over time. After building and installing a port, make clean will clean up the temporary work directory. To sweep the whole Ports Collection: &prompt.root; portsclean -C A lot of out-dated source distribution files will collect in distfiles over time. The following command will delete all the distfiles that are no longer referenced by any ports: &prompt.root; portsclean -D To remove all distfiles not referenced by any port currently installed on the system: &prompt.root; portsclean -DD The portsclean utility is part of the ports-mgmt/portupgrade suite. ports-mgmt/pkg_cutleaves automates the task of removing installed ports that are no longer needed. - Post-installation Activities - - After installing a new application you will normally want to - read any documentation it may have included, edit any - required configuration files, and ensure that the - application's service starts at boot time. - - The exact steps you need to take to configure each - application will obviously be different. However, if you have - just installed a new application and are wondering - What now? these tips might help: + Working With Installed Ports + + Most third party applications will need some level of + configuration after they were installed. This may be a simple + configuration file alteration, or perhaps the application will + just generate a configuration file. Most applications will + have documentation installed into + /usr/local/share/doc and + manual pages. This documentation should be consulted before + continuing. Some applications run services which must be added + to the /etc/rc.conf file before + starting. + + The following list contains useful information for + post-install port management. In several cases, finding + the location of binaries if they were installed outside + of the PATH. Users of &man.csh.1; should run + rehash to rebuild the known binary + list in the shells PATH. - Use &man.pkg.info.1; to find out which files were - installed, and where. For example, if you have just - installed FooPackage version 1.0.0, then this command + The &man.pkg.info.1; command will print all installed + files and their location. For example, if the FooPackage + version 1.0.0 was just installed, then the following + command will show all the files installed with the + package. - &prompt.root; pkg_info -L foopackage-1.0.0 | less + &prompt.root; pkg_info -L foopackage-1.0.0 | less - will show all the files installed by the package. Pay - special attention to files located in - man/, which will be manual pages, - etc/, which will be configuration - files, and doc/, which will be more - comprehensive documentation. + Configuration files are always installed in + /usr/local/etc + and should definitely be consulted before attempting + to use the new application. To determine which version of the application was installed: &prompt.root; pkg_info | grep -i foopackage will find all the installed packages that have foopackage in the package name. Replace foopackage as necessary. - Once you have identified where the application's manual - pages have been installed, review them using &man.man.1;. - Review the sample configuration files and any additional - documentation that may have been provided. + These commands will also show the names of any manual + pages installed with the application. This additional + documentation will now be available to the &man.man.1; + command. - If the application has a web site, check it for - additional documentation, frequently asked questions, and so - forth. If you are not sure of the web site address it may - be listed in the output from + If the application has a web site, consult it for + additional documentation or a frequently asked questions + page. If the website is unknown, the following command + will be useful to print out this information if it's + available. &prompt.root; pkg_info foopackage-1.0.0 A WWW: line, if present, should provide a URL for the application's web site. Ports that should start at boot time usually install a startup script in /usr/local/etc/rc.d. Review this script for correctness and edit or rename it if needed. See Starting Services for more information. Dealing with Broken Ports When coming across a port that does not build or install: Find out if there is a fix pending for the port in the Problem Report database. If so, the proposed fix may work. Ask the maintainer of the port for help. Type make maintainer or read the Makefile to find the maintainer's email address. Remember to include the name and version of the port (send the $FreeBSD: line from the Makefile) and the output leading up to the error when you email the maintainer. Some ports are not maintained by an individual but instead by a mailing list. Many, but not all, of these addresses look like freebsd-listname@FreeBSD.org. Please take this into account when phrasing your questions. In particular, ports shown as maintained by ports@FreeBSD.org are actually not maintained by anyone. Fixes and support, if any, come from the general community who subscribe to that mailing list. More volunteers are always needed! If you do not get a response, use &man.send-pr.1; to submit a bug report (see Writing &os; Problem Reports). Fix it! The Porter's Handbook includes detailed information on the Ports infrastructure so that you can fix the occasional broken port or even submit your own! Use &man.pkg.add.1; to instead install the package. diff --git a/en_US.ISO8859-1/books/handbook/security/chapter.xml b/en_US.ISO8859-1/books/handbook/security/chapter.xml index 0beccf251e..df1fa9b1d0 100644 --- a/en_US.ISO8859-1/books/handbook/security/chapter.xml +++ b/en_US.ISO8859-1/books/handbook/security/chapter.xml @@ -1,4152 +1,3833 @@ Matthew Dillon Much of this chapter has been taken from the security(7) manual page by Security security Synopsis - This chapter will provide a basic introduction to system + This chapter provides a basic introduction to system security concepts, some general good rules of thumb, and some - advanced topics under &os;. A lot of the topics covered here - can be applied to system and Internet security in general as - well. The Internet is no longer a friendly place - in which everyone wants to be your kind neighbor. Securing your - system is imperative to protect your data, intellectual + advanced topics under &os;. Many of the topics covered here + can be applied to system and Internet security in general. + Securing a system is imperative to protect data, intellectual property, time, and much more from the hands of hackers and the like. - &os; provides an array of utilities and mechanisms to ensure - the integrity and security of your system and network. + &os; provides an array of utilities and mechanisms to + protect the integrity and security of the system and + network. After reading this chapter, you will know: - Basic system security concepts, in respect to - &os;. + Basic &os; system security concepts. - About the various crypt mechanisms available in &os;, - such as DES and - MD5. + The various crypt mechanisms available in &os;. How to set up one-time password authentication. How to configure TCP Wrappers for use - with inetd. + with &man.inetd.8;. - How to set up Kerberos5 on + How to set up Kerberos on &os;. How to configure IPsec and create a - VPN between &os;/&windows; - machines. + VPN. How to configure and use - OpenSSH, &os;'s - SSH implementation. + OpenSSH on &os;. + + + + How to use filesystem ACLs. - What file system ACLs are and how to - use them. + How to use portaudit to + audit third party software packages installed from the + Ports Collection. - How to use the Portaudit - utility to audit third party software packages installed - from the Ports Collection. + How to utilize &os; security advisories. - How to utilize the &os; security advisories - publications. + What Process Accounting is and how to enable it on + &os;. - Have an idea of what Process Accounting is and how to - enable it on &os;. + Understand the resource limits database and + how to utilize it to control user resources. Before reading this chapter, you should: Understand basic &os; and Internet concepts. - Additional security topics are covered throughout this book. - For example, Mandatory Access Control is discussed in and Internet Firewalls are discussed in . + Additional security topics are covered elsewhere in this + Handbook. For example, Mandatory Access Control is discussed in + and Internet firewalls are discussed in + . Introduction Security is a function that begins and ends with the system - administrator. While all BSD &unix; multi-user systems have - some inherent security, the job of building and maintaining - additional security mechanisms to keep those users - honest is probably one of the single largest - undertakings of the sysadmin. Machines are only as secure as - you make them, and security concerns are ever competing with the - human necessity for convenience. &unix; systems, in general, - are capable of running a huge number of simultaneous processes - and many of these processes operate as servers — meaning - that external entities can connect and talk to them. As - yesterday's mini-computers and mainframes become today's - desktops, and as computers become networked and inter-networked, - security becomes an even bigger issue. + administrator. While &os; provides some inherent security, the + job of configuring and maintaining additional security + mechanisms is probably one of the single largest undertakings of + the sysadmin. System security also pertains to dealing with various forms of attack, including attacks that attempt to crash, or otherwise make a system unusable, but do not attempt to compromise the - root account (break root). - Security concerns can be split up into several - categories: + root account. Security concerns can be + split up into several categories: Denial of service attacks. User account compromises. - Root compromise through accessible servers. + Root compromise through accessible services. Root compromise via user accounts. Backdoor creation. DoS attacks Denial of Service (DoS) security DoS attacks Denial of Service (DoS) Denial of Service (DoS) - A denial of service attack is an action that deprives the - machine of needed resources. Typically, DoS attacks are - brute-force mechanisms that attempt to crash or otherwise make a - machine unusable by overwhelming its servers or network stack. - Some DoS attacks try to take advantage of bugs in the networking - stack to crash a machine with a single packet. The latter can - only be fixed by applying a bug fix to the kernel. Attacks on - servers can often be fixed by properly specifying options to + A Denial of Service DoS attack is an + action that deprives the machine of needed resources. + Typically, DoS attacks are brute-force + mechanisms that attempt to crash or otherwise make a machine + unusable by overwhelming its services or network stack. Attacks + on servers can often be fixed by properly specifying options to limit the load the servers incur on the system under adverse conditions. Brute-force network attacks are harder to deal - with. A spoofed-packet attack, for example, is nearly - impossible to stop, short of cutting your system off from the - Internet. It may not be able to take your machine down, but it - can saturate your Internet connection. + with. This type of attack may not be able to take the machine + down, but it can saturate the Internet connection. security account compromises - A user account compromise is even more common than a DoS - attack. Many sysadmins still run standard - telnetd, - rlogind, - rshd, and - ftpd servers on their machines. - These servers, by default, do not operate over encrypted - connections. The result is that if you have any moderate-sized - user base, one or more of your users logging into your system - from a remote location (which is the most common and convenient - way to login to a system) will have his or her password sniffed. - The attentive system admin will analyze his remote access logs - looking for suspicious source addresses even for successful - logins. - - One must always assume that once an attacker has access to a - user account, the attacker can break root. - However, the reality is that in a well secured and maintained - system, access to a user account does not necessarily give the - attacker access to root. The distinction - is important because without access to root - the attacker cannot generally hide his tracks and may, at best, - be able to do nothing more than mess with the user's files, or - crash the machine. User account compromises are very common + A user account compromise is more common than a + DoS attack. Many sysadmins still run + unencrypted services, meaning that users logging into the + system from a remote location are vulnerable to having their + password sniffed. The attentive sysadmin analyzes the remote + access logs looking for suspicious source addresses and + suspicious logins. + + In a well secured and maintained system, access to a user + account does not necessarily give the attacker access to + root. Without root + access, the attacker cannot generally hide his tracks and may, + at best, be able to do nothing more than mess with the user's + files or crash the machine. User account compromises are common because users tend not to take the precautions that sysadmins take. security backdoors - System administrators must keep in mind that there are - potentially many ways to break root on a - machine. The attacker may know the root - password, the attacker may find a bug in a root-run server and - be able to break root over a network - connection to that server, or the attacker may know of a bug in - a suid-root program that allows the attacker to break - root once he has broken into a user's - account. If an attacker has found a way to break - root on a machine, the attacker may not - have a need to install a backdoor. Many of the - root holes found and closed to date involve - a considerable amount of work by the attacker to cleanup after - himself, so most attackers install backdoors. A backdoor - provides the attacker with a way to easily regain - root access to the system, but it also - gives the smart system administrator a convenient way to detect - the intrusion. Making it impossible for an attacker to install - a backdoor may actually be detrimental to your security, because - it will not close off the hole the attacker found to break in - the first place. + There are potentially many ways to break + root: the attacker may know the + root password, the attacker may exploit a + bug in a service which runs as root, or the + attacker may know of a bug in a SUID-root program. An attacker + may utilize a program known as a backdoor to search for + vulnerable systems, take advantage of unpatched exploits to + access a system, and hide traces of illegal activity. Security remedies should always be implemented with a multi-layered onion peel approach and can be categorized as follows: - Securing root and staff + Secure root and staff accounts. - Securing root–run servers - and suid/sgid binaries. + Secure root–run servers + and SUID/SGID binaries. - Securing user accounts. + Secure user accounts. - Securing the password file. + Secure the password file. - Securing the kernel core, raw devices, and - file systems. + Secure the kernel core, raw devices, and + filesystems. Quick detection of inappropriate changes made to the system. Paranoia. - The next section of this chapter will cover the above bullet - items in greater depth. + The next section covers these items in greater depth. Securing &os; security securing &os; - - Command Versus Protocol - - Throughout this document, we will use - bold text to refer to an - application, and a monospaced font to refer - to specific commands. Protocols will use a normal font. This - typographical distinction is useful for instances such as ssh, - since it is a protocol as well as command. - - - The sections that follow will cover the methods of securing - your &os; system that were mentioned in the last section of this - chapter. + This section describes methods for securing a &os; system + against the attacks that were mentioned in the previous section. - Securing the <username>root</username> Account and - Staff Accounts + Securing the <username>root</username> Account - su + &man.su.1; - First off, do not bother securing staff accounts if you - have not secured the root account. Most + Most systems have a password assigned to the - root account. The first thing you do is - assume that the password is always - compromised. This does not mean that you should remove the - password. The password is almost always necessary for console - access to the machine. What it does mean is that you should - not make it possible to use the password outside of the - console or possibly even with the &man.su.1; command. For - example, make sure that your ptys are specified as being - insecure in the /etc/ttys file so that - direct root logins via - telnet or rlogin are - disallowed. If using other login services such as - sshd, make sure that direct - root logins are disabled there as well. - You can do this by editing your - /etc/ssh/sshd_config file, and making - sure that PermitRootLogin is set to - no. Consider every access method — - services such as FTP often fall through the cracks. Direct - root logins should only be allowed via - the system console. + root account. Assume that this password + is always at risk of being compromised. + This does not mean that the password should be disabled as the + password is almost always necessary for console access to the + machine. However, it should not be possible to use this + password outside of the console or possibly even with + &man.su.1;. For example, setting the entries in + /etc/ttys to insecure + prevents root logins to the specified + terminals. In &os;, root logins using + &man.ssh.1; are disabled by default as + PermitRootLogin is set to + no in + /etc/ssh/sshd_config. Consider every + access method as services such as FTP often fall through the + cracks. Direct root logins should only + be allowed via the system console. wheel - Of course, as a sysadmin you have to be able to get to - root, so we open up a few holes. But we - make sure these holes require additional password verification - to operate. One way to make root - accessible is to add appropriate staff accounts to the - wheel group (in - /etc/group). The staff members placed in - the wheel group are allowed to - su to root. You - should never give staff members native - wheel access by putting them in the - wheel group in their password entry. - Staff accounts should be placed in a - staff group, and then added to the - wheel group via the - /etc/group file. Only those staff - members who actually need to have root - access should be placed in the wheel - group. It is also possible, when using an authentication - method such as Kerberos, to use Kerberos' - .k5login file in the - root account to allow a &man.ksu.1; to - root without having to place anyone at - all in the wheel group. This may be - the better solution since the wheel - mechanism still allows an intruder to break - root if the intruder has gotten hold of - your password file and can break into a staff account. While - having the wheel mechanism is better - than having nothing at all, it is not necessarily the safest - option. - - To lock an account completely, the &man.pw.8; command - should be used: + Since a sysadmin needs access to + root, additional password verification + should be configured. One method is to add appropriate user + accounts to wheel in + /etc/group. Members of + wheel are allowed to &man.su.1; to + root. Only those users who actually need + to have root access should be placed in + wheel. When using Kerberos for + authentication, create a .k5login in + the home directory of root to allow + &man.ksu.1; to be used without having to place anyone in + wheel. + + To lock an account completely, use &man.pw.8;: &prompt.root; pw lock staff - This will prevent the user from logging in using any - mechanism, including &man.ssh.1;. + This will prevent the specified user from logging in using + any mechanism, including &man.ssh.1;. Another method of blocking access to accounts would be to replace the encrypted password with a single * character. This character - would never match the encrypted password and thus block user - access. For example, the following staff account: + would never match the encrypted password and thus blocks user + access. For example, the entry for the following + account: foobar:R9DT/Fa1/LV9U:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh - Should be changed to this: + could be changed to this using &man.vipw.8;: foobar:*:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh - This will prevent the foobar user - from logging in using conventional methods. This method for - access restriction is flawed on sites using + This prevents foobar from logging in + using conventional methods. This method for access + restriction is flawed on sites using Kerberos or in situations where the user has set up keys with &man.ssh.1;. - These security mechanisms also assume that you are logging + These security mechanisms assume that users are logging in from a more restrictive server to a less restrictive - server. For example, if your main box is running all sorts of - servers, your workstation should not be running any. In order - for your workstation to be reasonably secure you should run as - few servers as possible, up to and including no servers at - all, and you should run a password-protected screen blanker. - Of course, given physical access to a workstation an attacker - can break any sort of security you put on it. This is - definitely a problem that you should consider, but you should - also consider the fact that the vast majority of break-ins - occur remotely, over a network, from people who do not have - physical access to your workstation or servers. - - Using something like Kerberos also gives you the ability - to disable or change the password for a staff account in one - place, and have it immediately affect all the machines on - which the staff member may have an account. If a staff - member's account gets compromised, the ability to instantly - change his password on all machines should not be underrated. - With discrete passwords, changing a password on N machines can - be a mess. You can also impose re-passwording restrictions - with Kerberos: not only can a Kerberos ticket be made to - timeout after a while, but the Kerberos system can require - that the user choose a new password after a certain period of - time (say, once a month). + server. For example, if the server is running network + services, the workstation should not be running any. In + order for a workstation to be reasonably secure, run zero or + as few services as possible and run a password-protected + screensaver. Of course, given physical access to any system, + an attacker can break any sort of security. Fortunately, + many break-ins occur remotely, over a network, from people who + do not have physical access to the system. + + Using Kerberos provides the ability to disable or change + the password for a user in one place, and have it immediately + affect all the machines on which the user has an account. If + an account is compromised, the ability to instantly change the + associated password on all machines should not be underrated. + Additional restrictions can be imposed with Kerberos: a + Kerberos ticket can be configured to timeout and the Kerberos + system can require that the user choose a new password after a + configurable period of time. Securing Root-run Servers and SUID/SGID Binaries - - ntalk - - - comsat - - - finger - sandboxes - sshd - - - telnetd - - - rshd - - - rlogind - - - The prudent sysadmin only runs the servers he needs to, no - more, no less. Be aware that third party servers are often - the most bug-prone. For example, running an old version of - imapd or - popper is like giving a universal - root ticket out to the entire world. - Never run a server that you have not checked out carefully. - Many servers do not need to be run as - root. For example, the - ntalk, - comsat, and - finger daemons can be run in - special user sandboxes. A sandbox is - not perfect, unless you go through a large amount of trouble, - but the onion approach to security still stands: If someone is - able to break in through a server running in a sandbox, they - still have to break out of the sandbox. The more layers the - attacker must break through, the lower the likelihood of his - success. Root holes have historically been found in virtually - every server ever run as root, including - basic system servers. If you are running a machine through - which people only login via sshd - and never login via telnetd or - rshd or - rlogind, then turn off those - services! - - &os; now defaults to running - ntalkd, - comsat, and - finger in a sandbox. Another - program which may be a candidate for running in a sandbox is - &man.named.8;. /etc/defaults/rc.conf - includes the arguments necessary to run - named in a sandbox in a - commented-out form. Depending on whether you are installing a - new system or upgrading an existing system, the special user - accounts used by these sandboxes may not be installed. The - prudent sysadmin would research and implement sandboxes for - servers whenever possible. - - - sendmail + &man.sshd.8; - There are a number of other servers that typically do not - run in sandboxes: sendmail, - popper, - imapd, - ftpd, and others. There are - alternatives to some of these, but installing them may require - more work than you are willing to perform (the convenience - factor strikes again). You may have to run these servers as - root and rely on other mechanisms to - detect break-ins that might occur through them. - - The other big potential root holes in - a system are the suid-root and sgid binaries installed on the - system. Most of these binaries, such as - rlogin, reside in /bin, /sbin, The prudent sysadmin only enables required services and is + aware that third party servers are often the most bug-prone. + Never run a server that has not been checked out carefully. + Think twice before running any service as + root as many daemons can be run as a + separate service account or can be started in a + sandbox. Do not activate insecure + services such as &man.telnetd.8; or &man.rlogind.8;. + + Another potential security hole is SUID-root and SGID + binaries. Most of these binaries, such as &man.rlogin.1;, + reside in /bin, + /sbin, /usr/bin, or /usr/sbin. While nothing is - 100% safe, the system-default suid and sgid binaries can be - considered reasonably safe. Still, root - holes are occasionally found in these binaries. A - root hole was found in - Xlib in 1998 that made - xterm (which is typically suid) - vulnerable. It is better to be safe than sorry and the - prudent sysadmin will restrict suid binaries, that only staff - should run, to a special group that only staff can access, and - get rid of (chmod 000) any suid binaries - that nobody uses. A server with no display generally does not - need an xterm binary. Sgid - binaries can be almost as dangerous. If an intruder can break - an sgid-kmem binary, the intruder might be able to read + 100% safe, the system-default SUID and SGID binaries can be + considered reasonably safe. It is recommended to restrict + SUID binaries to a special group that only staff can access, + and to delete any unused SUID binaries. SGID binaries can be + almost as dangerous. If an intruder can break an SGID-kmem + binary, the intruder might be able to read /dev/kmem and thus read the encrypted - password file, potentially compromising any passworded - account. Alternatively an intruder who breaks group + password file, potentially compromising user accounts. + Alternatively, an intruder who breaks group kmem can monitor keystrokes sent through ptys, including ptys used by users who login through secure methods. An intruder that breaks the tty group can write to almost any user's tty. If a user is running a terminal program or emulator with a keyboard-simulation feature, the intruder can potentially generate a data stream that causes the user's terminal to echo a command, which is then run as that user. Securing User Accounts User accounts are usually the most difficult to secure. - While you can impose draconian access restrictions on your - staff and star out their passwords, you may not - be able to do so with any general user accounts you might - have. If you do have sufficient control, then you may win out - and be able to secure the user accounts properly. If not, you - simply have to be more vigilant in your monitoring of those - accounts. Use of ssh and Kerberos for user accounts is more - problematic, due to the extra administration and technical - support required, but still a very good solution compared to a - encrypted password file. + Be vigilant in the monitoring of user accounts. Use of + &man.ssh.1; and Kerberos for user accounts requires extra + administration and technical support, but provides a good + solution compared to an encrypted password file. Securing the Password File The only sure fire way is to star out as many passwords as - you can and use ssh or Kerberos for access to those accounts. - Even though the encrypted password file + possible and use &man.ssh.1; or Kerberos for access to those + accounts. Even though the encrypted password file (/etc/spwd.db) can only be read by root, it may be possible for an intruder to obtain read access to that file even if the attacker cannot obtain root-write access. - Your security scripts should always check for and report - changes to the password file (see the Security scripts should be used to check for and report + changes to the password file as described in the Checking file integrity - section below). + section. Securing the Kernel Core, Raw Devices, and - File Systems - - If an attacker breaks root he can do - just about anything, but there are certain conveniences. For - example, most modern kernels have a packet sniffing device - driver built in. Under &os; it is called the - bpf device. An intruder will - commonly attempt to run a packet sniffer on a compromised - machine. You do not need to give the intruder the capability - and most systems do not have the need for the - bpf device compiled in. + Filesystems + + Most modern kernels have a packet sniffing device driver + built in. Under &os; it is called + bpf. This device is needed for DHCP, + but can be removed in the custom kernel configuration file of + systems that do not provide or use DHCP. - sysctl + &man.sysctl.8; - But even if you turn off the bpf - device, you still have /dev/mem and - /dev/kmem to worry about. For that - matter, the intruder can still write to raw disk devices. - Also, there is another kernel feature called the module - loader, &man.kldload.8;. An enterprising intruder can use a - KLD module to install his own bpf - device, or other sniffing device, on a running kernel. To - avoid these problems you have to run the kernel at a higher - secure level, at least securelevel 1. - - The secure level of the kernel can be set in a variety of - ways. The simplest way of raising the secure level of a - running kernel is through a sysctl on the - kern.securelevel kernel variable: + Even if bpf is disabled, + /dev/mem and + /dev/kmem are still problematic. An + intruder can still write to raw disk devices. An enterprising + intruder can use &man.kldload.8; to install his own + bpf, or another sniffing device, on a + running kernel. To avoid these problems, run the kernel at a + higher security level, at least security level 1. + + The security level of the kernel can be set in a variety + of ways. The simplest way of raising the security level of a + running kernel is to set + kern.securelevel: &prompt.root; sysctl kern.securelevel=1 - By default, the &os; kernel boots with a secure level of - -1. The secure level will remain at -1 unless it is altered, - either by the administrator or by &man.init.8; because of a - setting in the start up scripts. The secure level may be - raised during system startup by setting the - kern_securelevel_enable variable to - YES in the - /etc/rc.conf file, and the value of the - kern_securelevel variable to the desired - secure level. - - The default secure level of a &os; system right after the - startup scripts are done is -1. This is called - insecure mode because immutable file flags may - be turned off, all devices may be read from or written to, and - so on. - - Once the secure level is set to 1 or a higher value, the + By default, the &os; kernel boots with a security level of + -1. This is called insecure mode because + immutable file flags may be turned off and all devices may be + read from or written to. The security level will remain at -1 + unless it is altered, either by the administrator or by + &man.init.8;, because of a setting in the startup scripts. + The security level may be raised during system startup by + setting + kern_securelevel_enable to + YES in /etc/rc.conf, + and the value of kern_securelevel to the + desired security level. + + Once the security level is set to 1 or a higher value, the append-only and immutable files are honored, they cannot be - turned off, and access to raw devices will be denied. Higher + turned off, and access to raw devices is denied. Higher levels restrict even more operations. For a full description - of the effect of various secure levels, please read the - &man.security.7; manual page. + of the effect of various security levels, refer to + &man.security.7; and &man.init.8;. - Bumping the secure level to 1 or higher may cause a few - problems to X11 (access to /dev/io will - be blocked), or to the installation of &os; built from - source (the installworld part of - the process needs to temporarily reset the append-only and - immutable flags of some files), and in a few other cases. - Sometimes, as in the case of X11, it may be possible to work - around this by starting &man.xdm.1; pretty early in the boot - process, when the securelevel is still low enough. - Workarounds like this may not be possible for all secure + Bumping the security level to 1 or higher may cause a + few problems to &xorg;, as access + to /dev/io will be blocked, or to the + installation of &os; built from source as + installworld needs to temporarily + reset the append-only and immutable flags of some files. + In the case of &xorg;, it may be + possible to work around this by starting &man.xdm.1; early + in the boot process, when the security level is still low + enough. Workarounds may not be possible for all secure levels or for all the potential restrictions they enforce. A bit of forward planning is a good idea. Understanding the - restrictions imposed by each secure level is important as + restrictions imposed by each security level is important as they severely diminish the ease of system use. It will also make choosing a default setting much simpler and prevent any surprises. - If the kernel's secure level is raised to 1 or a higher + If the kernel's security level is raised to 1 or a higher value, it may be useful to set the schg - flag on critical startup binaries, directories, and script - files (i.e., everything that gets run up to the point where - the securelevel is set). This might be overdoing it, and - upgrading the system is much more difficult when it operates - at a high secure level. A less strict compromise is to run - the system at a higher secure level but skip setting the - schg flag for every system file and - directory under the sun. Another possibility is to simply + flag on critical startup binaries, directories, script files, + and everything that gets run up to the point where the + security level is set. A less strict compromise is to run + the system at a higher security level but skip setting the + schg flag. Another possibility is to mount / and /usr read-only. It should be noted that being too draconian about what is permitted may - prevent the all-important detection of an intrusion. + prevent detection of an intrusion. - Checking File Integrity: Binaries, Configuration Files, - Etc. - - When it comes right down to it, you can only protect your - core system configuration and control files so much before the - convenience factor rears its ugly head. For example, using - chflags to set the schg - bit on most of the files in Checking File Integrity + + One can only protect the core system configuration and + control files so much before the convenience factor rears its + ugly head. For example, using &man.chflags.1; to set the + schg bit on most of the files in / and /usr is probably counterproductive, because while it may protect the files, it - also closes a detection window. The last layer of your - security onion is perhaps the most important — - detection. The rest of your security is pretty much useless - (or, worse, presents you with a false sense of security) if - you cannot detect potential intrusions. Half the job of the - onion is to slow down the attacker, rather than stop him, in - order to be able to catch him in the act. + also closes an intrusion detection window. Security measures + are useless or, worse, present a false sense of security, if + potential intrusions cannot be detected. Half the job of + security is to slow down, not stop, an attacker, in order to + catch him in the act. The best way to detect an intrusion is to look for modified, missing, or unexpected files. The best way to look - for modified files is from another (often centralized) - limited-access system. Writing your security scripts on the - extra-secure limited-access system makes them mostly invisible - to potential attackers, and this is important. In order to - take maximum advantage you generally have to give the - limited-access box significant access to the other machines in - the business, usually either by doing a read-only NFS export - of the other machines to the limited-access box, or by setting - up ssh key-pairs to allow the limited-access box to ssh to the - other machines. Except for its network traffic, NFS is the - least visible method — allowing you to monitor the file - systems on each client box virtually undetected. If your - limited-access server is connected to the client boxes through - a switch, the NFS method is often the better choice. If your - limited-access server is connected to the client boxes through - a hub, or through several layers of routing, the NFS method - may be too insecure (network-wise) and using ssh may be the - better choice even with the audit-trail tracks that ssh - lays. - - Once you have given a limited-access box at least read - access to the client systems it is supposed to monitor, you - must write scripts to do the actual monitoring. Given an NFS - mount, you can write scripts out of simple system utilities - such as &man.find.1; and &man.md5.1;. It is best to - physically md5 the client-box files at least once a day, and + for modified files is from another, often centralized, + limited-access system. Writing security scripts on the + extra-security limited-access system makes them mostly + invisible to potential attackers. In order to take maximum + advantage, the limited-access box needs significant access to + the other machines, usually either through a read-only + NFS export or by setting up + &man.ssh.1; key-pairs. Except for its network traffic, + NFS is the least visible method, allowing + the administrator to monitor the filesystems on each client + box virtually undetected. If a limited-access server is + connected to the client boxes through a switch, the + NFS method is often the better choice. If + a limited-access server is connected to the client boxes + through several layers of routing, the NFS + method may be too insecure and &man.ssh.1; may be the better + choice. + + Once a limited-access box has been given at least read + access to the client systems it is supposed to monitor, create + the monitoring scripts. Given an NFS + mount, write scripts out of simple system utilities such as + &man.find.1; and &man.md5.1;. It is best to physically + &man.md5.1; the client system's files at least once a day, and to test control files such as those found in /etc and /usr/local/etc even more often. When mismatches are found, relative to the base md5 information the limited-access machine knows is valid, it - should scream at a sysadmin to go check it out. A good - security script will also check for inappropriate suid - binaries and for new or deleted files on system partitions - such as / and / and /usr. - When using ssh rather than NFS, writing the security - script is much more difficult. You essentially have to - scp the scripts to the client box in order - to run them, making them visible, and for safety you also need - to scp the binaries (such as find) that - those scripts use. The ssh client - on the client box may already be compromised. All in all, - using ssh may be necessary when running over insecure links, - but it is also a lot harder to deal with. - - A good security script will also check for changes to user - and staff members access configuration files: - .rhosts, .shosts, - .ssh/authorized_keys and so forth, files - that might fall outside the purview of the + When using &man.ssh.1; rather than NFS, + writing the security script is more difficult. For example, + &man.scp.1; is needed to send the scripts to the client box in + order to run them. The &man.ssh.1; client on the client box + may already be compromised. Using &man.ssh.1; may be + necessary when running over insecure links, but it is harder + to deal with. + + A good security script will also check for changes to + hidden configuration files, such as + .rhosts and + .ssh/authorized_keys, as these files + might fall outside the purview of the MD5 check. - If you have a huge amount of user disk space, it may take - too long to run through every file on those partitions. In - this case, setting mount flags to disallow suid binaries is a - good idea. The nosuid option (see - &man.mount.8;) is what you want to look into. You should - probably scan them anyway, at least once a week, since the - object of this layer is to detect a break-in attempt, whether - or not the attempt succeeds. + For a large amount of user disk space, it may take too + long to run through every file on those partitions. In this + case, consider setting mount flags to disallow SUID binaries + by using nosuid with &man.mount.8;. Scan + these partitions at least once a week, since the objective is + to detect a break-in attempt, whether or not the attempt + succeeds. Process accounting (see &man.accton.8;) is a relatively - low-overhead feature of the operating system which might help - as a post-break-in evaluation mechanism. It is especially - useful in tracking down how an intruder has actually broken - into a system, assuming the file is still intact after the - break-in has occurred. + low-overhead feature of &os; which might help as a + post-break-in evaluation mechanism. It is especially useful + in tracking down how an intruder broke into a system, assuming + the file is still intact after the break-in has + occurred. Finally, security scripts should process the log files, and the logs themselves should be generated in as secure a - manner as possible — remote syslog can be very useful. - An intruder will try to cover his tracks, and log files are + manner as possible and sent to a remote syslog server. An + intruder will try to cover his tracks, and log files are critical to the sysadmin trying to track down the time and method of the initial break-in. One way to keep a permanent record of the log files is to run the system console to a serial port and collect the information to a secure machine monitoring the consoles. Paranoia A little paranoia never hurts. As a rule, a sysadmin can - add any number of security features, as long as they do not - affect convenience, and can add security features that + add any number of security features which do not affect + convenience and can add security features that do affect convenience with some added - thought. Even more importantly, a security administrator - should mix it up a bit — if you use recommendations such - as those given by this document verbatim, you give away your - methodologies to the prospective attacker who also has access - to this document. + thought. More importantly, a security administrator should + mix it up a bit. If recommendations, such as those mentioned + in this section, are applied verbatim, those methodologies are + given to the prospective attacker who also has access to this + document. Denial of Service Attacks Denial of Service (DoS) - This section covers Denial of Service attacks. A DoS - attack is typically a packet attack. While there is not much - you can do about modern spoofed packet attacks that saturate - your network, you can generally limit the damage by ensuring - that the attacks cannot take down your servers by: + A DoS attack is typically a packet + attack. While there is not much one can do about spoofed + packet attacks that saturate a network, one can generally + limit the damage by ensuring that the attack cannot take down + servers by: Limiting server forks. - Limiting springboard attacks (ICMP response attacks, - ping broadcast, etc.). + Limiting springboard attacks such as ICMP response + attacks and ping broadcasts. - Overloading the Kernel Route Cache. + Overloading the kernel route cache. - A common DoS attack scenario is attacking a forking server - and making it spawn so many child processes that the host - system eventually runs out of memory, file descriptors, etc. - and then grinds to a halt. inetd - (see &man.inetd.8;) has several options to limit this sort of - attack. It should be noted that while it is possible to - prevent a machine from going down, it is not generally - possible to prevent a service from being disrupted by the - attack. Read the inetd manual page - carefully and pay specific attention to the + A common DoS attack scenario is to + force a forking server to spawn so many child processes that + the host system eventually runs out of memory and file + descriptors, and then grinds to a halt. There are several + options to &man.inetd.8; to limit this sort of attack. It + should be noted that while it is possible to prevent a machine + from going down, it is not generally possible to prevent a + service from being disrupted by the attack. Read + &man.inetd.8; carefully and pay specific attention to , , and - options. Note that spoofed-IP attacks - will circumvent the option to - inetd, so typically a combination - of options must be used. Some standalone servers have - self-fork-limitation parameters. - - Sendmail has its - option, which tends to - work much better than trying to use + . Spoofed IP attacks will circumvent + to &man.inetd.8;, so typically a + combination of options must be used. Some standalone servers + have self-fork-limitation parameters. + + Sendmail provides + , which tends to work + better than trying to use Sendmail's load limiting options - due to the load lag. You should specify a - MaxDaemonChildren parameter, when you start - sendmail; high enough to handle - your expected load, but not so high that the computer cannot - handle that number of Sendmail - instances without falling on its face. It is also prudent to - run Sendmail in queued mode - () and to run the daemon - (sendmail -bd) separate from the queue-runs - (sendmail -q15m). If you still want - real-time delivery you can run the queue at a much lower - interval, such as , but be sure to - specify a reasonable MaxDaemonChildren - option for that - Sendmail to prevent cascade - failures. - - Syslogd can be attacked - directly and it is strongly recommended that you use the - option whenever possible, and the - option otherwise. - - You should also be fairly careful with connect-back - services such as TCP Wrapper's - reverse-identd, which can be attacked directly. You generally - do not want to use the reverse-ident feature of - TCP Wrapper for this reason. - - It is a very good idea to protect internal services from - external access by firewalling them off at your border - routers. The idea here is to prevent saturation attacks from - outside your LAN, not so much to protect internal services - from network-based root compromise. - Always configure an exclusive firewall, i.e., firewall - everything except ports A, B, C, D, and - M-Z. This way you can firewall off all of your low - ports except for certain specific services such as - named (if you are primary for a - zone), ntalkd, - sendmail, and other - Internet-accessible services. If you try to configure the - firewall the other way — as an inclusive or permissive - firewall, there is a good chance that you will forget to - close a couple of services, or that you will - add a new internal service and forget to update the firewall. - You can still open up the high-numbered port range on the - firewall, to allow permissive-like operation, without - compromising your low ports. Also take note that &os; allows - you to control the range of port numbers used for dynamic - binding, via the various - net.inet.ip.portrange - sysctl's (sysctl -a | fgrep - portrange), which can also ease the complexity of - your firewall's configuration. For example, you might use a - normal first/last range of 4000 to 5000, and a hiport range of - 49152 to 65535, then block off everything under 4000 in your - firewall (except for certain specific Internet-accessible - ports, of course). - - Another common DoS attack is called a springboard attack - — to attack a server in a manner that causes the server - to generate responses which overloads the server, the local - network, or some other machine. The most common attack of - this nature is the ICMP ping broadcast - attack. The attacker spoofs ping packets sent to - your LAN's broadcast address with the source IP address set to - the actual machine they wish to attack. If your border - routers are not configured to stomp on ping packets to - broadcast addresses, your LAN winds up generating sufficient - responses to the spoofed source address to saturate the - victim, especially when the attacker uses the same trick on - several dozen broadcast addresses over several dozen different - networks at once. Broadcast attacks of over a hundred and - twenty megabits have been measured. A second common - springboard attack is against the ICMP error reporting system. - By constructing packets that generate ICMP error responses, an - attacker can saturate a server's incoming network and cause - the server to saturate its outgoing network with ICMP - responses. This type of attack can also crash the server by - running it out of memory, especially if the server cannot - drain the ICMP responses it generates fast enough. Use the - sysctl variable + due to the load lag. Specify a + MaxDaemonChildren when starting + Sendmail which is high enough to + handle the expected load, but not so high that the computer + cannot handle that number of + Sendmail instances. It is prudent + to run Sendmail in queued mode + using and to run the + daemon (sendmail -bd) separate from the + queue-runs (sendmail -q15m). For + real-time delivery, run the queue at a much lower interval, + such as , but be sure to specify a + reasonable MaxDaemonChildren to prevent + cascade failures. + + &man.syslogd.8; can be attacked directly and it is + strongly recommended to use + whenever possible, and + otherwise. + + Be careful with connect-back services such as + reverse-identd, which can be attacked directly. The + reverse-ident feature of + TCP Wrappers is not recommended for + this reason. + + It is recommended to protect internal services from + external access by firewalling them at the border routers. + This is to prevent saturation attacks from outside the LAN, + not so much to protect internal services from network-based + root compromise. Always configure an + exclusive firewall which denies everything by default except + for traffic which is explicitly allowed. The range of port + numbers used for dynamic binding in &os; is controlled by + several net.inet.ip.portrange + &man.sysctl.8; variables. + + Another common DoS attack, called a + springboard attack, causes the server to generate responses + which overloads the server, the local network, or some other + machine. The most common attack of this nature is the + ICMP ping broadcast attack. The attacker + spoofs ping packets sent to the LAN's broadcast address with + the source IP address set to the machine to attack. If the + border routers are not configured to drop ping packets sent to + broadcast addresses, the LAN generates sufficient responses to + the spoofed source address to saturate the victim, especially + when the attack is against several dozen broadcast addresses + over several dozen different networks at once. A second + common springboard attack constructs packets that generate + ICMP error responses which can saturate a server's incoming + network and cause the server to saturate its outgoing network + with ICMP responses. This type of attack can crash the + server by running it out of memory, especially if the server + cannot drain the ICMP responses it generates fast enough. Use + the &man.sysctl.8; variable net.inet.icmp.icmplim to limit these attacks. The last major class of springboard attacks is - related to certain internal inetd - services such as the udp echo service. An attacker simply - spoofs a UDP packet with the source address being server A's - echo port, and the destination address being server B's echo - port, where server A and B are both on your LAN. The two - servers then bounce this one packet back and forth between - each other. The attacker can overload both servers and their - LANs simply by injecting a few packets in this manner. - Similar problems exist with the internal - chargen port. A competent sysadmin - will turn off all of these inetd-internal test - services. - - Spoofed packet attacks may also be used to overload the - kernel route cache. Refer to the + related to certain internal &man.inetd.8; services such as the + UDP echo service. An attacker spoofs a UDP packet with a + source address of server A's echo port and a destination + address of server B's echo port, where server A and B on the + same LAN. The two servers bounce this one packet back and + forth between each other. The attacker can overload both + servers and the LAN by injecting a few packets in this manner. + Similar problems exist with the + chargen port. These inetd-internal + test services should remain disabled. + + Spoofed packet attacks may be used to overload the kernel + route cache. Refer to the net.inet.ip.rtexpire, rtminexpire, and - rtmaxcache sysctl - parameters. A spoofed packet attack that uses a random source - IP will cause the kernel to generate a temporary cached route - in the route table, viewable with netstat -rna | - fgrep W3. These routes typically timeout in 1600 + rtmaxcache &man.sysctl.8; parameters. A + spoofed packet attack that uses a random source IP will cause + the kernel to generate a temporary cached route in the route + table, viewable with netstat -rna | fgrep + W3. These routes typically timeout in 1600 seconds or so. If the kernel detects that the cached route - table has gotten too big it will dynamically reduce the + table has gotten too big, it will dynamically reduce the rtexpire but will never decrease it to less - than rtminexpire. There are two + than rtminexpire. This creates two problems: The kernel does not react quickly enough when a lightly loaded server is suddenly attacked. The rtminexpire is not low enough for the kernel to survive a sustained attack. - If your servers are connected to the Internet via a T3 or + If the servers are connected to the Internet via a T3 or better, it may be prudent to manually override both rtexpire and rtminexpire via &man.sysctl.8;. Never set either parameter to zero - (unless you want to crash the machine). Setting both - parameters to 2 seconds should be sufficient to protect the - route table from attack. + as this could crash the machine. Setting both parameters to 2 + seconds should be sufficient to protect the route table from + attack. - Access Issues with Kerberos and SSH - - ssh - - There are a few issues with both Kerberos and - ssh that need to be addressed if - you intend to use them. Kerberos 5 is an excellent - authentication protocol, but there are bugs in the kerberized - telnet and - rlogin applications that make them - unsuitable for dealing with binary streams. Also, by default - Kerberos does not encrypt a session unless you use the - option. ssh - encrypts everything by default. - - Ssh works quite well in every respect except that it - forwards encryption keys by default. What this means is that - if you have a secure workstation holding keys that give you - access to the rest of the system, and you ssh to an insecure - machine, your keys are usable. The actual keys themselves are - not exposed, but ssh installs a forwarding port for the - duration of your login, and if an attacker has broken - root on the insecure machine he can - utilize that port to use your keys to gain access to any other - machine that your keys unlock. - - We recommend that you use ssh in combination with Kerberos - whenever possible for staff logins. - Ssh can be compiled with Kerberos - support. This reduces your reliance on potentially exposed - ssh keys while at the same time protecting passwords via - Kerberos. Ssh keys should only be used for automated tasks - from secure machines (something that Kerberos is unsuited to - do). We also recommend that you either turn off - key-forwarding in the ssh configuration, or that you make use - of the from=IP/DOMAIN option that ssh - allows in its authorized_keys file to - make the key only usable to entities logging in from specific - machines. + Access Issues with Kerberos and &man.ssh.1; + + &man.ssh.1; + + There are a few issues with both Kerberos and &man.ssh.1; + that need to be addressed if they are used. Kerberos is an + excellent authentication protocol, but there are bugs in the + kerberized versions of &man.telnet.1; and &man.rlogin.1; that + make them unsuitable for dealing with binary streams. By + default, Kerberos does not encrypt a session unless + is used whereas &man.ssh.1; encrypts + everything. + + While &man.ssh.1; works well, it forwards encryption keys + by default. This introduces a security risk to a user who + uses &man.ssh.1; to access an insecure machine from a secure + workstation. The keys themselves are not exposed, but + &man.ssh.1; installs a forwarding port for the duration of the + login. If an attacker has broken root on + the insecure machine, he can utilize that port to gain access + to any other machine that those keys unlock. + + It is recommended that &man.ssh.1; is used in combination + with Kerberos whenever possible for staff logins and + &man.ssh.1; can be compiled with Kerberos support. This + reduces reliance on potentially exposed SSH + keys while protecting passwords via Kerberos. Keys should + only be used for automated tasks from secure machines as this + is something that Kerberos is unsuited to. It is recommended + to either turn off key-forwarding in the + SSH configuration, or to make use + of from=IP/DOMAIN in + authorized_keys to make the key only + usable to entities logging in from specific machines. Bill Swingle Parts rewritten and updated by DES, Blowfish, MD5, SHA256, SHA512, and Crypt security crypt crypt Blowfish DES MD5 SHA256 SHA512 Every user on a &unix; system has a password associated with - their account. It seems obvious that these passwords need to be - known only to the user and the actual operating system. In - order to keep these passwords secret, they are encrypted with - what is known as a one-way hash, that is, they - can only be easily encrypted but not decrypted. In other words, - what we told you a moment ago was obvious is not even true: the - operating system itself does not really - know the password. It only knows the + their account. In order to keep these passwords secret, they + are encrypted with a one-way hash, as they can + be easily encrypted but not decrypted. The operating system + itself does not know the password. It only knows the encrypted form of the password. The only way to get the plain-text password is by a brute force search of the space of possible passwords. - Unfortunately the only secure way to encrypt passwords when - &unix; came into being was based on DES, the Data Encryption - Standard. This was not such a problem for users resident in the - US, but since the source code for DES could not be exported - outside the US, &os; had to find a way to both comply with US - law and retain compatibility with all the other &unix; variants - that still used DES. - - The solution was to divide up the encryption libraries so - that US users could install the DES libraries and use DES but - international users still had an encryption method that could be - exported abroad. This is how &os; came to use MD5 as its - default encryption method. MD5 is believed to be more secure - than DES, so installing DES is offered primarily for - compatibility reasons. + Originally, the only secure way to encrypt passwords in + &unix; was based on the Data Encryption Standard + (DES). Since the source code for + DES could not be exported outside the US, + &os; had to find a way to both comply with US law and retain + compatibility with other &unix; variants that used + DES. The solution was MD5 which is believed + to be more secure than DES. - Recognizing Your Crypt Mechanism - - Currently the library supports DES, MD5, Blowfish, SHA256, - and SHA512 hash functions. By default &os; 9.1 and later - uses SHA512 to encrypt passwords. Older versions use MD5 by - default. - - It is pretty easy to identify which encryption method &os; - is set up to use. Examining the encrypted passwords in the - /etc/master.passwd file is one way. - Passwords encrypted with the MD5 hash are longer than those - encrypted with the DES hash and also begin with the characters + Recognizing the Crypt Mechanism + + Currently the library supports DES, + MD5, Blowfish, SHA256, and SHA512 hash functions. To identify + which encryption method &os; is set up to use, examine the + encrypted passwords in + /etc/master.passwd. Passwords encrypted + with the MD5 hash are longer than those encrypted with the + DES hash and begin with the characters $1$. Passwords starting with $2a$ are encrypted with the - Blowfish hash function. DES password strings do not have any - particular identifying characteristics, but they are shorter - than MD5 passwords, and are coded in a 64-character alphabet - which does not include the $ - character, so a relatively short string which does not begin - with a dollar sign is very likely a DES password. Both SHA256 - and SHA512 begin with the characters + Blowfish hash function. DES password + strings do not have any particular identifying + characteristics, but they are shorter than MD5 passwords, and + are coded in a 64-character alphabet which does not include + the $ character, so a relatively + short string which does not begin with a dollar sign is very + likely a DES password. Both SHA256 and + SHA512 begin with the characters $6$. The password format used for new passwords is controlled by the passwd_format login capability in /etc/login.conf, which takes values of des, md5, blf, sha256 or - sha512. See the &man.login.conf.5; manual - page for more information about login capabilities. + sha512. Refer to &man.login.conf.5; for + more information about login capabilities. One-time Passwords one-time passwords security one-time passwords - By default, &os; includes support for OPIE (One-time - Passwords In Everything), which uses the MD5 hash by + By default, &os; includes support for One-time Passwords In + Everything (OPIE), which uses the MD5 hash by default. - There are three different sorts of passwords which we will - discuss below. The first is your usual &unix; style or Kerberos - password; we will call this a &unix; password. - The second sort is the one-time password which is generated by - the OPIE &man.opiekey.1; program and accepted by the - &man.opiepasswd.1; program and the login prompt; we will call - this a one-time password. The final sort of - password is the secret password which you give to the - opiekey program (and sometimes the - opiepasswd programs) which it uses to - generate one-time passwords; we will call it a secret - password or just unqualified - password. - - The secret password does not have anything to do with your - &unix; password; they can be the same but this is not - recommended. OPIE secret passwords are not limited to 8 + There are three different types of passwords. The first is + the usual &unix; style or Kerberos password. The second is the + one-time password which is generated by &man.opiekey.1; and + accepted by &man.opiepasswd.1; and the login prompt. The final + type of password is the secret password used by + &man.opiekey.1;, and sometimes &man.opiepasswd.1;, to generate + one-time passwords. + + The secret password has nothing to do with the &unix; + password. They can be the same, but this is not recommended. + OPIE secret passwords are not limited to 8 characters like old &unix; passwordsUnder &os; the standard login password may be up to 128 characters in - length., they can be as long as you like. - Passwords of six or seven word long phrases are fairly common. - For the most part, the OPIE system operates completely - independently of the &unix; password system. + length.. Passwords of six or seven word + long phrases are fairly common. For the most part, the + OPIE system operates completely independently + of the &unix; password system. Besides the password, there are two other pieces of data - that are important to OPIE. One is what is known as the + that are important to OPIE. One is the seed or key, consisting of two - letters and five digits. The other is what is called the - iteration count, a number between 1 and 100. - OPIE creates the one-time password by concatenating the seed and - the secret password, then applying the MD5 hash as many times as - specified by the iteration count and turning the result into six - short English words. These six English words are your one-time - password. The authentication system (primarily PAM) keeps track - of the last one-time password used, and the user is - authenticated if the hash of the user-provided password is equal - to the previous password. Because a one-way hash is used it is - impossible to generate future one-time passwords if a - successfully used password is captured; the iteration count is - decremented after each successful login to keep the user and the - login program in sync. When the iteration count gets down to 1, - OPIE must be reinitialized. - - There are a few programs involved in each system which we - will discuss below. The opiekey program - accepts an iteration count, a seed, and a secret password, and - generates a one-time password or a consecutive list of one-time - passwords. The opiepasswd program is used to - initialize OPIE, and to change passwords, iteration counts, or - seeds; it takes either a secret passphrase, or an iteration - count, seed, and a one-time password. The - opieinfo program will examine the relevant - credentials files (/etc/opiekeys) and print - out the invoking user's current iteration count and seed. - - There are four different sorts of operations we will cover. - The first is using opiepasswd over a secure - connection to set up one-time-passwords for the first time, or - to change your password or seed. The second operation is using - opiepasswd over an insecure connection, in - conjunction with opiekey over a secure - connection, to do the same. The third is using - opiekey to log in over an insecure - connection. The fourth is using opiekey to - generate a number of keys which can be written down or printed - out to carry with you when going to some location without secure - connections to anywhere. + letters and five digits. The other is the iteration + count, a number between 1 and 100. + OPIE creates the one-time password by + concatenating the seed and the secret password, applying the MD5 + hash as many times as specified by the iteration count, and + turning the result into six short English words. These six + English words are the one-time password. The authentication + system (primarily PAM) keeps track of the last one-time password + used, and the user is authenticated if the hash of the + user-provided password is equal to the previous password. + Because a one-way hash is used, it is impossible to generate + future one-time passwords if a successfully used password is + captured. The iteration count is decremented after each + successful login to keep the user and the login program in sync. + When the iteration count gets down to 1, + OPIE must be reinitialized. + + There are a few programs involved in this process. + &man.opiekey.1; accepts an iteration count, a seed, and a secret + password, and generates a one-time password or a consecutive + list of one-time passwords. In addition to initializing + OPIE, &man.opiepasswd.1; is used to change + passwords, iteration counts, or seeds. It takes either a secret + passphrase, or an iteration count, seed, and a one-time + password. The relevant credential files in + /etc/opiekeys are examined by + &man.opieinfo.1; which prints out the invoking user's current + iteration count and seed. + + There are four different sorts of operations. The first is + to use &man.opiepasswd.1; over a secure connection to set up + one-time-passwords for the first time, or to change the password + or seed. The second operation is to use &man.opiepasswd.1; over + an insecure connection, in conjunction with &man.opiekey.1; over + a secure connection, to do the same. The third is to use + &man.opiekey.1; to log in over an insecure connection. The + fourth is to use &man.opiekey.1; to generate a number of keys + which can be written down or printed out to carry to insecure + locations in order to make a connection to anywhere. Secure Connection Initialization - To initialize OPIE for the first time, execute the - opiepasswd command: + To initialize OPIE for the first time, + execute &man.opiepasswd.1;: &prompt.user; opiepasswd -c [grimreaper] ~ $ opiepasswd -f -c Adding unfurl: Only use this method from the console; NEVER from remote. If you are using telnet, xterm, or a dial-in, type ^C now or exit with no password. Then run opiepasswd without the -c parameter. Using MD5 to compute responses. Enter new secret pass phrase: Again new secret pass phrase: ID unfurl OTP key is 499 to4268 MOS MALL GOAT ARM AVID COED At the Enter new secret pass phrase: or - Enter secret password: prompts, you should - enter a password or phrase. Remember, this is not the - password that you will use to login with, this is used to - generate your one-time login keys. The ID line - gives the parameters of your particular instance: your login - name, the iteration count, and seed. When logging in the - system will remember these parameters and present them back to - you so you do not have to remember them. The last line gives - the particular one-time password which corresponds to those - parameters and your secret password; if you were to re-login - immediately, this one-time password is the one you would - use. + Enter secret password: prompt, enter a + password or phrase. This is not the login password as this + password is used to generate the one-time login keys. The + ID line gives the parameters of the instance: + the login name, iteration count, and seed. When logging in, + the system will remember these parameters and display them, + meaning that they do not have to be memorized. The last line + gives the particular one-time password which corresponds to + those parameters and the secret password. At the next login, + this one-time password is the one to use. Insecure Connection Initialization - To initialize or change your secret password over an - insecure connection, you will need to already have a secure - connection to some place where you can run - opiekey; this might be in the form of a - shell prompt on a machine you trust. You will also need to - make up an iteration count (100 is probably a good value), and - you may make up your own seed or use a randomly-generated one. - Over on the insecure connection (to the machine you are - initializing), use opiepasswd: + To initialize or change the secret password over an + insecure connection, a secure connection is needed to some + place where &man.opiekey.1; can be run. This might be a shell + prompt on a trusted machine. An iteration count is needed, + where 100 is probably a good value, and the seed can either be + specified or the randomly-generated one used. On the insecure + connection, the machine being initialized, use + &man.opiepasswd.1;: &prompt.user; opiepasswd Updating unfurl: You need the response from an OTP generator. Old secret pass phrase: otp-md5 498 to4268 ext Response: GAME GAG WELT OUT DOWN CHAT New secret pass phrase: otp-md5 499 to4269 Response: LINE PAP MILK NELL BUOY TROY ID mark OTP key is 499 gr4269 LINE PAP MILK NELL BUOY TROY - To accept the default seed press Return. - Then before entering an access password, move over to your - secure connection and give it the same parameters: + To accept the default seed, press Return. + Before entering an access password, move over to the secure + connection and give it the same parameters: &prompt.user; opiekey 498 to4268 Using the MD5 algorithm to compute response. -Reminder: Don't use opiekey from telnet or dial-in sessions. +Reminder: Do not use opiekey from telnet or dial-in sessions. Enter secret pass phrase: GAME GAG WELT OUT DOWN CHAT - Now switch back over to the insecure connection, and copy - the one-time password generated over to the relevant + Switch back over to the insecure connection, and copy + the generated one-time password over to the relevant program. Generating a Single One-time Password - Once you have initialized OPIE and login, you will be - presented with a prompt like this: + After initializing OPIE and logging in, + a prompt like this will be displayed: &prompt.user; telnet example.com Trying 10.0.0.1... Connected to example.com Escape character is '^]'. FreeBSD/i386 (example.com) (ttypa) login: <username> otp-md5 498 gr4269 ext Password: - As a side note, the OPIE prompts have a useful feature - (not shown here): if you press Return at the - password prompt, the prompter will turn echo on, so you can - see what you are typing. This can be extremely useful if you - are attempting to type in a password by hand, such as from a - printout. + The OPIE prompts provides a useful + feature. If Return is pressed at the + password prompt, the prompt will turn echo on and display + what is typed. This can be useful when attempting to type in + a password by hand from a printout. MS-DOS Windows MacOS - At this point you need to generate your one-time password - to answer this login prompt. This must be done on a trusted - system that you can run opiekey on. (There - are versions of these for DOS, &windows; and &macos; as well.) - They need the iteration count and the seed as command line - options. You can cut-and-paste these right from the login - prompt on the machine that you are logging in to. + At this point, generate the one-time password to answer + this login prompt. This must be done on a trusted system + where it is safe to run &man.opiekey.1;. There are versions + of this command for &windows;, &macos; and &os;. This command + needs the iteration count and the seed as command line + options. Use cut-and-paste from the login prompt on the + machine being logged in to. On the trusted system: &prompt.user; opiekey 498 to4268 Using the MD5 algorithm to compute response. -Reminder: Don't use opiekey from telnet or dial-in sessions. +Reminder: Do not use opiekey from telnet or dial-in sessions. Enter secret pass phrase: GAME GAG WELT OUT DOWN CHAT - Now that you have your one-time password you can continue - logging in. + Once the one-time password is generated, continue to log + in. Generating Multiple One-time Passwords - Sometimes you have to go places where you do not have - access to a trusted machine or secure connection. In this - case, it is possible to use the opiekey - command to generate a number of one-time passwords beforehand - to be printed out and taken with you. For example: + Sometimes there is no access to a trusted machine or + secure connection. In this case, it is possible to use + &man.opiekey.1; to generate a number of one-time passwords + beforehand. For example: &prompt.user; opiekey -n 5 30 zz99999 Using the MD5 algorithm to compute response. -Reminder: Don't use opiekey from telnet or dial-in sessions. +Reminder: Do not use opiekey from telnet or dial-in sessions. Enter secret pass phrase: <secret password> 26: JOAN BORE FOSS DES NAY QUIT 27: LATE BIAS SLAY FOLK MUCH TRIG 28: SALT TIN ANTI LOON NEAL USE 29: RIO ODIN GO BYE FURY TIC 30: GREW JIVE SAN GIRD BOIL PHI The requests five keys in sequence, - the specifies what the last iteration + and specifies what the last iteration number should be. Note that these are printed out in - reverse order of eventual use. If you - are really paranoid, you might want to write the results down - by hand; otherwise you can cut-and-paste into - lpr. Note that each line shows both the - iteration count and the one-time password; you may still find - it handy to scratch off passwords as you use them. + reverse order of use. The really + paranoid might want to write the results down by hand; + otherwise, print the list. Each line shows both the iteration + count and the one-time password. Scratch off the passwords as + they are used. Restricting Use of &unix; Passwords - OPIE can restrict the use of &unix; passwords based on the - IP address of a login session. The relevant file is - /etc/opieaccess, which is present by - default. Please check &man.opieaccess.5; for more information - on this file and which security considerations you should be - aware of when using it. + OPIE can restrict the use of &unix; + passwords based on the IP address of a login session. The + relevant file is /etc/opieaccess, which + is present by default. Refer to &man.opieaccess.5; for more + information on this file and which security considerations to + be aware of when using it. - Here is a sample opieaccess - file: + Here is a sample opieaccess: permit 192.168.0.0 255.255.0.0 This line allows users whose IP source address (which is vulnerable to spoofing) matches the specified value and mask, to use &unix; passwords at any time. If no rules in opieaccess are - matched, the default is to deny non-OPIE logins. + matched, the default is to deny non-OPIE + logins. Tom Rhodes Written by TCP Wrappers TCP Wrappers - Anyone familiar with &man.inetd.8; has probably heard of - TCP Wrappers at some point. But few - individuals seem to fully comprehend its usefulness in a network - environment. It seems that everyone wants to install a firewall - to handle network connections. While a firewall has a wide - variety of uses, there are some things that a firewall will not - handle, such as sending text back to the connection originator. - The TCP Wrappers software does this and much - more. In the next few sections many of the - TCP Wrappers features will be discussed, and, - when applicable, example configuration lines will be - provided. - - The TCP Wrappers software extends the - abilities of inetd to provide support - for every server daemon under its control. Using this method it - is possible to provide logging support, return messages to - connections, permit a daemon to only accept internal - connections, etc. While some of these features can be provided - by implementing a firewall, this will add not only an extra - layer of protection but go beyond the amount of control a - firewall can provide. - - The added functionality of TCP Wrappers - should not be considered a replacement for a good firewall. - TCP Wrappers can be used in conjunction - with a firewall or other security enhancements though and - it can serve nicely as an extra layer of protection - for the system. - - Since this is an extension to the configuration of - inetd, the reader is expected have - read the inetd - configuration section. - - - While programs run by &man.inetd.8; are not exactly - daemons, they have traditionally been called - daemons. This is the term we will use in this section - too. - + TCP Wrappers extends the abilities of + to provide support for every + server daemon under its control. It can be configured + to provide logging support, return messages to connections, and + permit a daemon to only accept internal connections. While some + of these features can be provided by implementing a firewall, + TCP Wrappers adds an extra layer of + protection and goes beyond the amount of control a firewall can + provide. + + TCP Wrappers should not be considered a + replacement for a properly configured firewall. + TCP Wrappers should be used in conjunction + with a firewall and other security enhancements. Initial Configuration - The only requirement of using TCP - Wrappers in &os; is to ensure the - inetd server is started from - rc.conf with the - option; this is the default setting. Of course, proper - configuration of /etc/hosts.allow is also - expected, but &man.syslogd.8; will throw messages in the - system logs in these cases. + To enable TCP Wrappers in &os;, ensure + the &man.inetd.8; server is started from + /etc/rc.conf with + . Then, properly configure + /etc/hosts.allow. Unlike other implementations of TCP Wrappers, the use of hosts.deny has been deprecated. All configuration options should be placed in /etc/hosts.allow. In the simplest configuration, daemon connection policies are set to either be permitted or blocked depending on the options in /etc/hosts.allow. The default configuration in &os; is to allow a connection to every daemon - started with inetd. Changing this - will be discussed only after the basic configuration is - covered. + started with &man.inetd.8;. Basic configuration usually takes the form of - daemon : address : action. Where - daemon is the daemon name which - inetd started. The - address can be a valid hostname, an - IP address or an IPv6 address enclosed in - brackets ([ ]). The action field can - be either allow or deny - to grant or deny access appropriately. Keep in mind that - configuration works off a first rule match semantic, meaning - that the configuration file is scanned in ascending order for - a matching rule. When a match is found the rule is applied - and the search process will halt. - - Several other options exist but they will be explained - in a later section. A simple configuration line may easily be - constructed from that information alone. For example, to - allow POP3 connections via the - mail/qpopper daemon, - the following lines should be appended to + daemon : address : action, where + daemon is the daemon which &man.inetd.8; + started, address is a valid hostname, + IP address, or an IPv6 address enclosed in + brackets ([ ]), and action is + either allow or deny. + TCP Wrappers uses a first rule match + semantic, meaning that the configuration file is scanned in + ascending order for a matching rule. When a match is found, + the rule is applied and the search process stops. + + For example, to allow POP3 connections + via the mail/qpopper + daemon, the following lines should be appended to hosts.allow: # This line is required for POP3 connections: qpopper : ALL : allow - After adding this line, inetd - will need to be restarted by using &man.service.8;: + After adding this line, &man.inetd.8; needs to be + restarted: &prompt.root; service inetd restart Advanced Configuration - TCP Wrappers has advanced options too; - they will allow for more control over the way connections are - handled. In some cases it may be a good idea to return a - comment to certain hosts or daemon connections. In other - cases, perhaps a log file should be recorded or an email sent - to the administrator. Other situations may require the use of - a service for local connections only. This is all possible + TCP Wrappers provides advanced options + to allow more control over the way connections are handled. + In some cases, it may be appropriate to return a comment to + certain hosts or daemon connections. In other cases, a log + entry should be recorded or an email sent to the + administrator. Other situations may require the use of a + service for local connections only. This is all possible through the use of configuration options known as wildcards, expansion characters and - external command execution. The next two sections are written - to cover these situations. + external command execution. External Commands Suppose that a situation occurs where a connection should be denied yet a reason should be sent to the - individual who attempted to establish that connection. How - could it be done? That action can be made possible by using - the option. When a connection - attempt is made, will be called to - execute a shell command or script. An example already - exists in the hosts.allow file: + individual who attempted to establish that connection. That + action is possible with . When a + connection attempt is made, executes + a shell command or script. An example exists in + hosts.allow: # The rest of the daemons are protected. ALL : ALL \ : severity auth.info \ : twist /bin/echo "You are not welcome to use %d from %h." - This example shows that the message, - You are not allowed to use daemon - from hostname. will be returned - for any daemon not previously configured in the access file. - This is extremely useful for sending a reply back to the - connection initiator right after the established connection - is dropped. Note that any message returned - must be wrapped in quote - " characters; there are no exceptions to - this rule. + In this example, the message You are not allowed + to use daemon from + hostname. will be returned for + any daemon not previously configured in the access file. + This is useful for sending a reply back to the connection + initiator right after the established connection is dropped. + Any message returned must be wrapped in + quote (") characters. It may be possible to launch a denial of service attack on the server if an attacker, or group of attackers, could flood these daemons with connection requests. - Another possibility is to use the - option in these cases. Like , the - option implicitly denies the - connection and may be used to run external shell commands or - scripts. Unlike , - will not send a reply back to the - individual who established the connection. For an example, - consider the following configuration line: + Another possibility is to use . + Like , + implicitly denies the connection and may be used to run + external shell commands or scripts. Unlike + , will not send + a reply back to the individual who established the + connection. For example, consider the following + configuration line: # We do not allow connections from example.com: ALL : .example.com \ : spawn (/bin/echo %a from %h attempted to access %d >> \ /var/log/connections.log) \ : deny - This will deny all connection attempts from the *.example.com domain; simultaneously - logging the hostname, IP address and the - daemon which they attempted to access in the - /var/log/connections.log file. + This will deny all connection attempts from *.example.com and log the hostname, + IP address, and the daemon to which + access was attempted to + /var/log/connections.log. - Aside from the already explained substitution characters - above, e.g., %a, a few others exist. See - the &man.hosts.access.5; manual page for the complete - list. + This example uses the substitution characters + %a and %h. Refer to + &man.hosts.access.5; for the complete list. Wildcard Options - Thus far the ALL option has been used - continuously throughout the examples. Other options exist - which could extend the functionality a bit further. For - instance, ALL may be used to match every - instance of either a daemon, domain or an - IP address. Another wildcard available - is PARANOID which may be used to match + The ALL option may be used to match + every instance of a daemon, domain, or an + IP address. Another wildcard is + PARANOID which may be used to match any host which provides an IP address - that may be forged. In other words, + that may be forged. For example, PARANOID may be used to define an action to be taken whenever a connection is made from an IP address that differs from its - hostname. The following example may shed some more light on - this discussion: + hostname. In this example, all connection requests to + &man.sendmail.8; which have an IP address + that varies from its hostname will be denied: # Block possibly spoofed requests to sendmail: sendmail : PARANOID : deny - In that example all connection requests to - sendmail which have an - IP address that varies from its hostname - will be denied. - Using the PARANOID wildcard may severely cripple servers if the client or server has a broken DNS setup. Administrator discretion is advised. To learn more about wildcards and their associated - functionality, see the &man.hosts.access.5; manual - page. + functionality, refer to &man.hosts.access.5;. Before any of the specific configuration lines above will work, the first configuration line should be commented - out in hosts.allow. This was noted at - the beginning of this section. + out in hosts.allow. Tillman Hodgson Contributed by Mark Murray Based on a contribution by <application>Kerberos5</application> Kerberos is a network add-on system/protocol that allows users to authenticate themselves - through the services of a secure server. Services such as - remote login, remote copy, secure inter-system file copying and - other high-risk tasks are made considerably safer and more - controllable. - - Kerberos can be described as an + through the services of a secure server. + Kerberos can be described as an identity-verifying proxy system. It can also be described as a - trusted third-party authentication system. - Kerberos provides only one function - — the secure authentication of users on the network. It - does not provide authorization functions (what users are allowed - to do) or auditing functions (what those users did). After a - client and server have used Kerberos - to prove their identity, they can also encrypt all of their - communications to assure privacy and data integrity as they go - about their business. - - Therefore it is highly recommended that - Kerberos be used with other security - methods which provide authorization and audit services. - - The following instructions can be used as a guide on how to - set up Kerberos as distributed for - &os;. However, you should refer to the relevant manual pages - for a complete description. + trusted third-party authentication system. After a user + authenticates with Kerberos, their + communications can be encrypted to assure privacy and data + integrity. + + The only function of Kerberos is + to provide the secure authentication of users on the network. + It does not provide authorization functions (what users are + allowed to do) or auditing functions (what those users did). It + is recommended that Kerberos be used + with other security methods which provide authorization and + audit services. + + This section provides a guide on how to set up + Kerberos as distributed for &os;. + Refer to the relevant manual pages for more complete + descriptions. For purposes of demonstrating a Kerberos installation, the various - name spaces will be handled as follows: + name spaces will be as follows: The DNS domain (zone) - will be example.org. + will be example.org. The Kerberos realm will be - EXAMPLE.ORG. + EXAMPLE.ORG. - Please use real domain names when setting up - Kerberos even if you intend to run - it internally. This avoids DNS problems + Use real domain names when setting up + Kerberos even if it will run + internally. This avoids DNS problems and assures inter-operation with other Kerberos realms. History Kerberos5 history Kerberos was created by MIT as a solution to network security problems. The Kerberos protocol uses strong cryptography so that a client can prove its identity to a server (and vice versa) across an insecure network connection. Kerberos is both the name of a network authentication protocol and an adjective to describe - programs that implement the program - (Kerberos telnet, for example). - The current version of the protocol is version 5, described in + programs that implement it, such as + Kerberos telnet. The current + version of the protocol is version 5, described in RFC 1510. Several free implementations of this protocol are available, covering a wide range of operating systems. The Massachusetts Institute of Technology (MIT), where Kerberos was originally developed, continues to develop their Kerberos package. It is commonly used in the US as - a cryptography product, as such it has historically been - affected by US export regulations. The + a cryptography product, and has historically been affected by + US export regulations. The MIT Kerberos is - available as a port (security/krb5). Heimdal - Kerberos is another version 5 - implementation, and was explicitly developed outside of the - US to avoid export regulations (and is thus - often included in non-commercial &unix; variants). The + available as the security/krb5 package or port. + Heimdal Kerberos is another version + 5 implementation, and was explicitly developed outside of the + US to avoid export regulations. The Heimdal Kerberos distribution is - available as a port (security/heimdal), and a minimal - installation of it is included in the base &os; + available as a the security/heimdal package or port, + and a minimal installation is included in the base &os; install. - In order to reach the widest audience, these instructions - assume the use of the Heimdal distribution included in - &os;. + These instructions assume the use of the Heimdal + distribution included in &os;. Setting up a Heimdal <acronym>KDC</acronym> Kerberos5 Key Distribution Center The Key Distribution Center (KDC) is the centralized authentication service that - Kerberos provides — it is the + Kerberos provides. It is the computer that issues Kerberos tickets. The KDC is considered trusted by all other computers in the Kerberos realm, and thus has heightened security concerns. - Note that while running the - Kerberos server requires very few - computing resources, a dedicated machine acting only as a - KDC is recommended for security - reasons. + While running the Kerberos + server requires very few computing resources, a dedicated + machine acting only as a KDC is recommended + for security reasons. To begin setting up a KDC, ensure that - your /etc/rc.conf file contains the - correct settings to act as a KDC (you may - need to adjust paths to reflect your own system): + /etc/rc.conf contains the correct + settings to act as a KDC. As required, + adjust paths to reflect the system: kerberos5_server_enable="YES" kadmind5_server_enable="YES" - Next we will set up your - Kerberos config file, - /etc/krb5.conf: + Next, edit /etc/krb5.conf as + follows: [libdefaults] default_realm = EXAMPLE.ORG [realms] EXAMPLE.ORG = { kdc = kerberos.example.org admin_server = kerberos.example.org } [domain_realm] .example.org = EXAMPLE.ORG - Note that this /etc/krb5.conf file - implies that your KDC will have the - fully-qualified hostname of kerberos.example.org. You will need to - add a CNAME (alias) entry to your zone file to accomplish this - if your KDC has a different - hostname. + This /etc/krb5.conf implies that the + KDC will use the fully-qualified hostname + kerberos.example.org. Add a + CNAME (alias) entry to the zone file to accomplish this + if the KDC has a different hostname. For large networks with a properly configured - BIND DNS server, the - above example could be trimmed to: + DNS server, the above example could be + trimmed to: [libdefaults] default_realm = EXAMPLE.ORG With the following lines being appended to the - example.org zonefile: + example.org zone file: _kerberos._udp IN SRV 01 00 88 kerberos.example.org. _kerberos._tcp IN SRV 01 00 88 kerberos.example.org. _kpasswd._udp IN SRV 01 00 464 kerberos.example.org. _kerberos-adm._tcp IN SRV 01 00 749 kerberos.example.org. _kerberos IN TXT EXAMPLE.ORG For clients to be able to find the - Kerberos services, you + Kerberos services, it must have either a fully configured /etc/krb5.conf or a minimally configured /etc/krb5.conf and a properly configured DNS server. - Next we will create the - Kerberos database. This database - contains the keys of all principals encrypted with a master - password. You are not required to remember this password, it - will be stored in a file - (/var/heimdal/m-key). To create the - master key, run kstash and enter a - password. - - Once the master key has been created, you can initialize - the database using the kadmin program with - the -l option (standing for - local). This option instructs - kadmin to modify the database files - directly rather than going through the - kadmind network service. This handles the - chicken-and-egg problem of trying to connect to the database - before it is created. Once you have the - kadmin prompt, use the - init command to create your realms initial - database. - - Lastly, while still in kadmin, create - your first principal using the add command. - Stick to the defaults options for the principal for now, you - can always change them later with the - modify command. Note that you can use the - ? command at any prompt to see the + Next, create the Kerberos + database which contains the keys of all principals encrypted + with a master password. It is not required to remember this + password as it will be stored in + /var/heimdal/m-key. To create the + master key, run &man.kstash.8; and enter a password. + + Once the master key has been created, initialize the + database using kadmin -l. This option + instructs &man.kadmin.8; to modify the local database files + directly rather than going through the &man.kadmind.8; network + service. This handles the chicken-and-egg problem of trying + to connect to the database before it is created. At the + &man.kadmin.8; prompt, use init to create + the realm's initial database. + + Lastly, while still in &man.kadmin.8;, create the first + principal using add. Stick to the default + options for the principal for now, as these can be changed + later with modify. Type + ? at the &man.kadmin.8; prompt to see the available options. A sample database creation session is shown below: &prompt.root; kstash Master key: xxxxxxxx Verifying password - Master key: xxxxxxxx &prompt.root; kadmin -l kadmin> init EXAMPLE.ORG Realm max ticket life [unlimited]: kadmin> add tillman Max ticket life [unlimited]: Max renewable life [unlimited]: Attributes []: Password: xxxxxxxx Verifying password - Password: xxxxxxxx - Now it is time to start up the KDC - services. Run service kerberos start and + Next, start the KDC services. Run + service kerberos start and service kadmind start to bring up the - services. Note that you will not have any kerberized daemons - running at this point but you should be able to confirm that - the KDC is functioning by obtaining and - listing a ticket for the principal (user) that you just + services. While there will not be any kerberized daemons + running at this point, it is possible to confirm that the + KDC is functioning by obtaining and + listing a ticket for the principal (user) that was just created from the command-line of the KDC itself: &prompt.user; kinit tillman tillman@EXAMPLE.ORG's Password: &prompt.user; klist Credentials cache: FILE:/tmp/krb5cc_500 Principal: tillman@EXAMPLE.ORG Issued Expires Principal Aug 27 15:37:58 Aug 28 01:37:58 krbtgt/EXAMPLE.ORG@EXAMPLE.ORG - The ticket can then be revoked when you have - finished: + The ticket can then be revoked when finished: &prompt.user; kdestroy <application>Kerberos</application> Enabling a Server with Heimdal Services Kerberos5 enabling services - First, we need a copy of the - Kerberos configuration file, - /etc/krb5.conf. To do so, simply copy - it over to the client computer from the - KDC in a secure fashion (using network - utilities, such as &man.scp.1;, or physically via a floppy - disk). - - Next you need a /etc/krb5.keytab - file. This is the major difference between a server - providing Kerberos enabled - daemons and a workstation — the server must have a - keytab file. This file contains the + First, copy + /etc/krb5.conf from the + KDC to the client computer in a secure + fashion, such as &man.scp.1;, or physically via a removable + media. + + Next, create /etc/krb5.keytab. + This is the major difference between a server providing + Kerberos enabled daemons and a + workstation: the server must have a + keytab. This file contains the server's host key, which allows it and the KDC to verify each others identity. It must be transmitted to the server in a secure fashion, as the security of the server can be broken if the key is made - public. This explicitly means that transferring it via a - clear text channel, such as FTP, is a - very bad idea. - - Typically, you transfer the keytab - to the server using the kadmin program. - This is handy because you also need to create the host - principal (the KDC end of the - krb5.keytab) using - kadmin. - - Note that you must have already obtained a ticket and - that this ticket must be allowed to use the - kadmin interface in the + public. + + Typically, the keytab is transferred + to the server using &man.kadmin.8;. This is handy because the + host principal, the KDC end of the + krb5.keytab, is also created using + &man.kadmin.8;. + + A ticket must already be obtained and this ticket must be + allowed to use the &man.kadmin.8; interface in the kadmind.acl. See the section titled - Remote administration in the Heimdal info - pages (info heimdal) for details on - designing access control lists. If you do not want to - enable remote kadmin access, you can - simply securely connect to the KDC (via - local console, &man.ssh.1; or - Kerberos &man.telnet.1;) and - perform administration locally using + Remote administration ininfo + heimdal for details on designing access control + lists. Instead of enabling remote &man.kadmin.8; access, the + administrator can securely connect to the + KDC via the local console or &man.ssh.1;, + and perform administration locally using kadmin -l. - After installing the /etc/krb5.conf - file, you can use kadmin from the - Kerberos server. The - add --random-key command will let you add - the server's host principal, and the ext - command will allow you to extract the server's host - principal to its own keytab. For example: + After installing /etc/krb5.conf, + use add --random-key from the + Kerberos server. This adds + the server's host principal. Then, use ext + to extract the server's host principal to its own keytab. For + example: &prompt.root; kadmin kadmin> add --random-key host/myserver.example.org Max ticket life [unlimited]: Max renewable life [unlimited]: Attributes []: kadmin> ext host/myserver.example.org kadmin> exit - Note that the ext command (short for - extract) stores the extracted key in - /etc/krb5.keytab by default. + Note that ext stores the extracted key + in /etc/krb5.keytab by default. - If you do not have kadmind running on - the KDC (possibly for security reasons) - and thus do not have access to kadmin - remotely, you can add the host principal + If &man.kadmind.8; is not running on the + KDC and there is no access to + &man.kadmin.8; remotely, add the host principal (host/myserver.EXAMPLE.ORG) directly on the KDC and then extract it to a - temporary file (to avoid over-writing the + temporary file to avoid overwriting the /etc/krb5.keytab on the - KDC) using something like this: + KDC, using something like this: &prompt.root; kadmin kadmin> ext --keytab=/tmp/example.keytab host/myserver.example.org kadmin> exit - You can then securely copy the keytab to the server - computer (using scp or a floppy, for - example). Be sure to specify a non-default keytab name to - avoid over-writing the keytab on the + The keytab can then be securely copied to the server + using &man.scp.1; or a removable media. Be sure to specify a + non-default keytab name to avoid overwriting the keytab on the KDC. - At this point your server can communicate with the - KDC (due to its - krb5.conf file) and it can prove its - own identity (due to the krb5.keytab - file). It is now ready for you to enable some - Kerberos services. For this - example we will enable the telnet service - by putting a line like this into your - /etc/inetd.conf and then restarting the - &man.inetd.8; service with service inetd + At this point, the server can communicate with the + KDC using + krb5.conf and it can prove its + own identity with krb5.keytab. It is now + ready for the Kerberos services to + be enabled. For this example, the &man.telnetd.8; service + is enabled in /etc/inetd.conf and + &man.inetd.8; has been restarted with service inetd restart: telnet stream tcp nowait root /usr/libexec/telnetd telnetd -a user - The critical bit is that the -a (for - authentication) type is set to user. Consult the - &man.telnetd.8; manual page for more details. + The critical change is that the + authentication type is set to user. Refer to &man.telnetd.8; + for more details. <application>Kerberos</application> Enabling a Client with Heimdal Kerberos5 configure clients - Setting up a client computer is almost trivially easy. - As far as Kerberos configuration - goes, you only need the Kerberos - configuration file, located at - /etc/krb5.conf. Simply securely copy - it over to the client computer from the + Setting up a client computer is easy as only + /etc/krb5.conf is needed. Securely copy + this file over to the client computer from the KDC. - Test your client computer by attempting to use - kinit, klist, and - kdestroy from the client to obtain, show, - and then delete a ticket for the principal you created - above. You should also be able to use - Kerberos applications to connect - to Kerberos enabled servers, - though if that does not work and obtaining a ticket does the - problem is likely with the server and not with the client or - the KDC. - - When testing an application like - telnet, try using a packet sniffer (such - as &man.tcpdump.1;) to confirm that your password is not - sent in the clear. Try using telnet with - the -x option, which encrypts the entire - data stream (similar to ssh). + Test the client by attempting to use &man.kinit.1;, + &man.klist.1;, and &man.kdestroy.1; from the client to obtain, + show, and then delete a ticket for the principal created + above. Kerberos applications + should also be able to connect to + Kerberos enabled servers. If that + does not work but obtaining a ticket does, the problem is + likely with the server and not with the client or the + KDC. + + When testing a Kerberized application, try using a packet + sniffer such as &man.tcpdump.1; to confirm that the password + is not sent in the clear. Various non-core Kerberos - client applications are also installed by default. This is - where the minimal nature of the base Heimdal - installation is felt: telnet is the only + client applications are available. The minimal + installation in &os; installs &man.telnetd.8; as the only Kerberos enabled service. - The Heimdal port adds some of the missing client - applications: Kerberos enabled - versions of ftp, rsh, - rcp, rlogin, and a few - other less common programs. The MIT port - also contains a full suite of + The Heimdal port installs + Kerberos enabled versions of + &man.ftpd.8;, &man.rshd.8;, &man.rcp.1;, &man.rlogind.8;, and + a few other less common programs. The MIT + port also contains a full suite of Kerberos client applications. User Configuration Files: <filename>.k5login</filename> and <filename>.k5users</filename> .k5login .k5users Users within a realm typically have their - Kerberos principal (such as - tillman@EXAMPLE.ORG) mapped to a local - user account (such as a local account named - tillman). Client applications such as - telnet usually do not require a user name - or a principal. - - Occasionally, however, you want to grant access to a - local user account to someone who does not have a matching - Kerberos principal. For example, - tillman@EXAMPLE.ORG may need access to - the local user account webdevelopers. - Other principals may also need access to that local - account. + Kerberos principal mapped to a + local user account. Occasionally, one needs to grant access + to a local user account to someone who does not have a + matching Kerberos principal. For + example, tillman@EXAMPLE.ORG may need + access to the local user account + webdevelopers. Other principals may also + need access to that local account. The .k5login and - .k5users files, placed in a users home - directory, can be used similar to a powerful combination of - .hosts and - .rhosts, solving this problem. For - example, if a .k5login with the - following contents: + .k5users files, placed in a user's home + directory, can be used to solve this problem. For example, if + .k5login with the following contents is + placed in the home directory of + webdevelopers, both principals listed + will have access to that account without requiring a shared + password.: tillman@example.org jdoe@example.org - Were to be placed into the home directory of the local - user webdevelopers then both principals - listed would have access to that account without requiring a - shared password. - - Reading the manual pages for these commands is - recommended. Note that the ksu manual - page covers .k5users. + Refer to &man.ksu.1; for more information about + .k5users. <application>Kerberos</application> Tips, Tricks, and Troubleshooting Kerberos5 troubleshooting When using either the Heimdal or MIT - Kerberos ports ensure that - your PATH environment variable lists the + Kerberos ports, ensure that + the PATH lists the Kerberos versions of the client applications before the system versions. - Do all the computers in your realm have synchronized - time settings? If not, authentication may fail. + If all the computers in the realm do not have + synchronized time settings, authentication may fail. describes how to synchronize clocks using NTP. - MIT and Heimdal inter-operate - nicely. Except for kadmin, the - protocol for which is not standardized. + MIT and Heimdal interoperate + except for &man.kadmin.8;, which is not + standardized. - If you change your hostname, you also need to change - your host/ principal and update - your keytab. This also applies to special keytab + If the hostname is changed, the + host/ principal must be changed and + the keytab updated. This also applies to special keytab entries like the www/ principal - used for Apache's - www/mod_auth_kerb. - All hosts in your realm must be resolvable (both - forwards and reverse) in DNS (or - /etc/hosts as a minimum). CNAMEs + All hosts in the realm must be both forward and + reverse resolvable in DNS or, at a + minimum, in /etc/hosts. CNAMEs will work, but the A and PTR records must be correct and - in place. The error message is not very intuitive: - Kerberos5 refuses authentication because Read - req failed: Key table entry not + in place. The error message for unresolvable hosts is not + intuitive: Kerberos5 refuses authentication + because Read req failed: Key table entry not found. - Some operating systems that may being acting as - clients to your KDC do not set the - permissions for ksu to be setuid - root. This means that - ksu does not work, which is a good - security idea but annoying. This is not a + Some operating systems that act as clients to the + KDC do not set the permissions for + &man.ksu.1; to be setuid root. This + means that &man.ksu.1; does not work. This is not a KDC error. With MIT - Kerberos, if you want to - allow a principal to have a ticket life longer than the - default ten hours, you must use - modify_principal in - kadmin to change the maxlife of both - the principal in question and the + Kerberos, in order to allow a + principal to have a ticket life longer than the default + ten hours, use modify_principal at the + &man.kadmin.8; prompt to change the maxlife of both the + principal in question and the krbtgt principal. Then the - principal can use the -l option with - kinit to request a ticket with a - longer lifetime. + principal can use kinit -l to request a + ticket with a longer lifetime. - If you run a packet sniffer on your - KDC to add in troubleshooting and - then run kinit from a workstation, - you will notice that your TGT is - sent immediately upon running kinit - — even before you type your password! The - explanation is that the + When running a packet sniffer on the + KDC to aid in troubleshooting while + running &man.kinit.1; from a workstation, the Ticket + Granting Ticket (TGT) is sent + immediately upon running &man.kinit.1;, even before the + password is typed. This is because the Kerberos server freely - transmits a TGT (Ticket Granting - Ticket) to any unauthorized request; however, every - TGT is encrypted in a key derived - from the user's password. Therefore, when a user - types their password it is not being sent to the - KDC, it is being used to decrypt - the TGT that - kinit already obtained. If the - decryption process results in a valid ticket with a - valid time stamp, the user has valid + transmits a TGT to any unauthorized + request. However, every TGT is + encrypted in a key derived from the user's password. + When a user types their password, it is not sent to the + KDC, it is instead used to decrypt + the TGT that &man.kinit.1; already + obtained. If the decryption process results in a valid + ticket with a valid time stamp, the user has valid Kerberos credentials. These credentials include a session key for establishing secure communications with the Kerberos server in the - future, as well as the actual ticket-granting ticket, - which is actually encrypted with the + future, as well as the actual TGT, + which is encrypted with the Kerberos server's own key. - This second layer of encryption is unknown to the - user, but it is what allows the + This second layer of encryption allows the Kerberos server to verify - the authenticity of each - TGT. + the authenticity of each TGT. - If you want to use long ticket lifetimes (a week, - for example) and you are using - OpenSSH to connect to the - machine where your ticket is stored, make sure that + To use long ticket lifetimes, such as a week, when + using OpenSSH to connect to the + machine where the ticket is stored, make sure that Kerberos is set to - no in your - sshd_config or else your tickets - will be deleted when you log out. + no in + sshd_config or else tickets will be + deleted at log out. - Remember that host principals can have a longer - ticket lifetime as well. If your user principal has a - lifetime of a week but the host you are connecting to - has a lifetime of nine hours, you will have an expired - host principal in your cache and the ticket cache will - not work as expected. + Host principals can have a longer ticket lifetime. If + the user principal has a lifetime of a week but the host + being connected to has a lifetime of nine hours, the user + cache will have an expired host principal and the ticket + cache will not work as expected. - When setting up a krb5.dict - file to prevent specific bad passwords from being used - (the manual page for kadmind covers - this briefly), remember that it only applies to - principals that have a password policy assigned to them. - The krb5.dict files format is - simple: one string per line. Creating a symbolic link - to /usr/share/dict/words might be + When setting up krb5.dict to + prevent specific bad passwords from being used as + described in &man.kadmind.8;, remember that it only + applies to principals that have a password policy assigned + to them. The format used in + krb5.dict is one string per line. + Creating a symbolic link to + /usr/share/dict/words might be useful. Differences with the <acronym>MIT</acronym> Port - The major difference between the MIT - and Heimdal installs relates to the - kadmin program which has a different (but - equivalent) set of commands and uses a different protocol. - This has a large implications if your KDC - is MIT as you will not be able to use the - Heimdal kadmin program to administer your - KDC remotely (or vice versa, for that - matter). - - The client applications may also take slightly different + The major difference between MIT and + Heimdal relates to &man.kadmin.8; which has a different, but + equivalent, set of commands and uses a different protocol. + If the KDC is MIT, the + Heimdal version of &man.kadmin.8; cannot be used to administer + the KDC remotely, and vice versa. + + The client applications may also use slightly different command line options to accomplish the same tasks. Following the instructions on the MIT - Kerberos web site - () is + Kerberos web site is recommended. Be careful of path issues: the - MIT port installs into - /usr/local/ by default, - and the normal system applications may be run - instead of MIT if your - PATH environment variable lists the system - directories first. + MIT port installs into /usr/local/ by default, and the + normal system applications run instead of + MIT versions if PATH lists + the system directories first. - With the MIT - security/krb5 port that - is provided by &os;, be sure to read the + With the &os; MIT security/krb5 port, be sure to + read /usr/local/share/doc/krb5/README.FreeBSD - file installed by the port if you want to understand why - logins via telnetd and - klogind behave somewhat oddly. Most - importantly, correcting the incorrect permissions on - cache file behavior requires that the + installed by the port to understand why logins via + &man.telnetd.8; and klogind behave + somewhat oddly. Correcting the incorrect permissions + on cache file behavior requires that the login.krb5 binary be used for authentication so that it can properly change ownership for the forwarded credentials. - The rc.conf must also be modified - to contain the following configuration: + The following edits should also be made to + rc.conf: kerberos5_server="/usr/local/sbin/krb5kdc" kadmind5_server="/usr/local/sbin/kadmind" kerberos5_server_enable="YES" kadmind5_server_enable="YES" This is done because the applications for - MIT kerberos installs binaries in the + MIT Kerberos installs binaries in the /usr/local hierarchy. Mitigating Limitations Found in <application>Kerberos</application> Kerberos5 limitations and shortcomings <application>Kerberos</application> is an - all-or-nothing approach + All or Nothing Approach Every service enabled on the network must be modified - to work with Kerberos (or be - otherwise secured against network attacks) or else the - users credentials could be stolen and re-used. An example + to work with Kerberos, or be + otherwise secured against network attacks, or else the + user's credentials could be stolen and re-used. An example of this would be Kerberos - enabling all remote shells (via rsh and - telnet, for example) but not converting - the POP3 mail server which sends - passwords in plain text. + enabling all remote shells but not converting the + POP3 mail server which sends passwords in + plain text. <application>Kerberos</application> is Intended for Single-User Workstations In a multi-user environment, - Kerberos is less secure. - This is because it stores the tickets in the - /tmp directory, which - is readable by all users. If a user is sharing a computer - with several other people simultaneously (i.e. - multi-user), it is possible that the user's tickets can be - stolen (copied) by another user. + Kerberos is less secure. This is + because it stores the tickets in /tmp, which is readable by + all users. If a user is sharing a computer with other + users, it is possible that the user's tickets can be stolen + or copied by another user. This can be overcome with the -c - filename command-line option or (preferably) the - KRB5CCNAME environment variable, but this - is rarely done. In principal, storing the ticket in the - users home directory and using simple file permissions can - mitigate this problem. + command-line option or, preferably, the + KRB5CCNAME environment variable. Storing + the ticket in the user's home directory and using file + permissions are commonly used to mitigate this + problem. The KDC is a Single Point of Failure - By design, the KDC must be as - secure as the master password database is contained on it. - The KDC should have absolutely no other - services running on it and should be physically secured. - The danger is high because + By design, the KDC must be as secure + as its master password database. The KDC + should have absolutely no other services running on it and + should be physically secure. The danger is high because Kerberos stores all passwords - encrypted with the same key (the master - key), which in turn is stored as a file on the - KDC. - - As a side note, a compromised master key is not quite - as bad as one might normally fear. The master key is only - used to encrypt the Kerberos - database and as a seed for the random number generator. - As long as access to your KDC is - secure, an attacker cannot do much with the master - key. + encrypted with the same master key which is + stored as a file on the KDC. + + A compromised master key is not quite as bad as one + might fear. The master key is only used to encrypt the + Kerberos database and as a seed + for the random number generator. As long as access to the + KDC is secure, an attacker cannot do much + with the master key. Additionally, if the KDC is - unavailable (perhaps due to a denial of service attack or - network problems) the network services are unusable as - authentication can not be performed, a recipe for a - denial-of-service attack. This can alleviated with - multiple KDCs (a single master and one - or more slaves) and with careful implementation of - secondary or fall-back authentication - (PAM is excellent for this). + unavailable, network services are unusable as authentication + cannot be performed. This can be alleviated with a single + master KDC and one or more slaves, and + with careful implementation of secondary or fall-back + authentication using PAM. <application>Kerberos</application> Shortcomings - Kerberos allows users, - hosts and services to authenticate between themselves. It - does not have a mechanism to authenticate the + Kerberos allows users, hosts + and services to authenticate between themselves. It does + not have a mechanism to authenticate the KDC to the users, hosts or services. - This means that a trojanned kinit (for - example) could record all user names and passwords. - Something like - security/tripwire or - other file system integrity checking tools can alleviate + This means that a trojanned &man.kinit.1; could record all + user names and passwords. Filesystem integrity checking + tools like security/tripwire can alleviate this. - Resources and further information + Resources and Further Information Kerberos5 external resources The Kerberos FAQ Designing an Authentication System: a Dialog in Four Scenes RFC 1510, The Kerberos Network Authentication Service (V5) MIT Kerberos home page Heimdal Kerberos home page Tom Rhodes Written by OpenSSL security OpenSSL - One feature that many users overlook is the - OpenSSL toolkit included in &os;. - OpenSSL provides an encryption - transport layer on top of the normal communications layer; - thus allowing it to be intertwined with many network - applications and services. - - Some uses of OpenSSL may - include encrypted authentication of mail clients, web based - transactions such as credit card payments and more. Many - ports such as + The + OpenSSL toolkit is included in &os;. + It provides an encryption transport layer on top of the normal + communications layer, allowing it to be intertwined with many + network applications and services. + + Some uses of OpenSSL may include + encrypted authentication of mail clients and web based + transactions such as credit card payments. Many ports such as www/apache22, and - mail/claws-mail will offer + mail/claws-mail offer compilation support for building with OpenSSL. - In most cases the Ports Collection will attempt to build + In most cases, the Ports Collection will attempt to build the security/openssl - port unless the WITH_OPENSSL_BASE make - variable is explicitly set to yes. + port unless WITH_OPENSSL_BASE is explicitly + set to yes. The version of OpenSSL included - in &os; supports Secure Sockets Layer v2/v3 (SSLv2/SSLv3), + in &os; supports Secure Sockets Layer v2/v3 (SSLv2/SSLv3) and Transport Layer Security v1 (TLSv1) network security protocols and can be used as a general cryptographic library. While OpenSSL supports the IDEA algorithm, it is disabled by default due to United States patents. To use it, the license should be reviewed and, if the restrictions are acceptable, the MAKE_IDEA variable must be set in - make.conf. + /etc/make.conf. One of the most common uses of OpenSSL is to provide certificates for use with software applications. These certificates ensure that the credentials of the company or individual are valid and not fraudulent. If the certificate in question has not - been verified by one of the several Certificate - Authorities, or CAs, a warning is - usually produced. A Certificate Authority is a company, such - as VeriSign, - which will sign certificates in order to validate credentials - of individuals or companies. This process has a cost - associated with it and is definitely not a requirement for - using certificates; however, it can put some of the more - paranoid users at ease. + been verified by a Certificate Authority + (CA), a warning is produced. A + CA is a company, such as VeriSign, signs + certificates in order to validate the credentials of individuals + or companies. This process has a cost associated with it and is + not a requirement for using certificates; however, it can put + users at ease. Generating Certificates OpenSSL certificate generation To generate a certificate, the following command is available: &prompt.root; openssl req -new -nodes -out req.pem -keyout cert.pem Generating a 1024 bit RSA private key ................++++++ .......................................++++++ writing new private key to 'cert.pem' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:US State or Province Name (full name) [Some-State]:PA Locality Name (eg, city) []:Pittsburgh Organization Name (eg, company) [Internet Widgits Pty Ltd]:My Company Organizational Unit Name (eg, section) []:Systems Administrator Common Name (eg, YOUR name) []:localhost.example.org Email Address []:trhodes@FreeBSD.org Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []:SOME PASSWORD An optional company name []:Another Name - Notice the response directly after the - Common Name prompt shows a domain name. This - prompt requires a server name to be entered for verification - purposes; placing anything but a domain name would yield a - useless certificate. Other options, for instance expire - time, alternate encryption algorithms, etc. are available. - A complete list may be obtained by viewing the - &man.openssl.1; manual page. - - Two files should now exist in the directory in which the - aforementioned command was issued. The certificate request, - req.pem, may be sent to a certificate - authority who will validate the credentials that you - entered, sign the request and return the certificate to you. - The second file created will be named + Notice the response directly after the Common + Name prompt shows a domain name. This prompt + requires a server name to be entered for verification + purposes and placing anything but a domain name yields a + useless certificate. Other options, such as the expire + time and alternate encryption algorithms, are available. A + complete list of options is described in + &man.openssl.1;. + + Two files should now exist in the directory in which this + command was issued. The certificate request, + req.pem, may be sent to a + CA who will validate the entered + credentials, sign the request, and return the signed + certificate. The second file is named cert.pem and is the private key for the - certificate and should be protected at all costs; if this + certificate and should be protected at all costs. If this falls in the hands of others it can be used to impersonate - you (or your server). + the user or the server. In cases where a signature from a CA is not required, a self signed certificate can be created. First, generate the RSA key: &prompt.root; openssl dsaparam -rand -genkey -out myRSA.key 1024 Next, generate the CA key: &prompt.root; openssl gendsa -des3 -out myca.key myRSA.key Use this key to create the certificate: &prompt.root; openssl req -new -x509 -days 365 -key myca.key -out new.crt Two new files should appear in the directory: a certificate authority signature file, myca.key and the certificate itself, new.crt. These should be placed in a - directory, preferably under - /etc, which is readable - only by root. Permissions of 0700 should - be fine for this and they can be set with the - chmod utility. + directory, preferably under /etc, which is readable only by + root. Permissions of 0700 are + appropriate and can be set using &man.chmod.1;. - Using Certificates, an Example + Using Certificates - So what can these files do? A good use would be to - encrypt connections to the + One use for a certificate is to encrypt connections to the Sendmail MTA. - This would dissolve the use of clear text authentication for - users who send mail via the local - MTA. + This prevents the use of clear text authentication for users + who send mail via the local MTA. - This is not the best use in the world as some - MUAs will present the user with an - error if they have not installed the certificate locally. - Refer to the documentation included with the software for - more information on certificate installation. + Some MUAs will display error if the + user has not installed the certificate locally. Refer to + the documentation included with the software for more + information on certificate installation. - The following lines should be placed inside the local + To configure Sendmail, the + following lines should be placed in the local .mc file: dnl SSL Options define(`confCACERT_PATH',`/etc/certs')dnl define(`confCACERT',`/etc/certs/new.crt')dnl define(`confSERVER_CERT',`/etc/certs/new.crt')dnl define(`confSERVER_KEY',`/etc/certs/myca.key')dnl define(`confTLS_SRV_OPTIONS', `V')dnl - Where /etc/certs/ - is the directory to be used for storing the certificate and - key files locally. The last few requirements are a rebuild - of the local .cf file. This is easily - achieved by typing make - install within the - /etc/mail directory. + In this example, /etc/certs/ + stores the certificate and key files locally. After saving + the edits, rebuild the local .cf file by + typing + make install + within /etc/mail. Follow that up with make restart which should start the Sendmail daemon. - If all went well there will be no error messages in the - /var/log/maillog file and + If all went well, there will be no error messages in + /var/log/maillog and Sendmail will show up in the process list. - For a simple test, simply connect to the mail server - using the &man.telnet.1; utility: + For a simple test, connect to the mail server using + &man.telnet.1;: &prompt.root; telnet example.com 25 Trying 192.0.34.166... Connected to example.com. Escape character is '^]'. 220 example.com ESMTP Sendmail 8.12.10/8.12.10; Tue, 31 Aug 2004 03:41:22 -0400 (EDT) ehlo example.com 250-example.com Hello example.com [192.0.34.166], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-8BITMIME 250-SIZE 250-DSN 250-ETRN 250-AUTH LOGIN PLAIN 250-STARTTLS 250-DELIVERBY 250 HELP quit 221 2.0.0 example.com closing connection Connection closed by foreign host. If the STARTTLS line appears in the - output then everything is working correctly. + output, everything is working correctly. Nik Clayton
nik@FreeBSD.org
 Written by - VPN over IPsec + <acronym>VPN</acronym> over IPsec IPsec - Creating a VPN between two networks, separated by the - Internet, using FreeBSD gateways. - Hiten M. Pandya
hmp@FreeBSD.org
 Written by Understanding IPsec - This section will guide you through the process of - setting up IPsec. In order to set up IPsec, it is necessary - that you are familiar with the concepts of building a custom + This section demonstrates the process of setting up IPsec. + It assumes familiarity with the concepts of building a custom kernel (see ). IPsec is a protocol which sits on - top of the Internet Protocol (IP) layer. It allows two or - more hosts to communicate in a secure manner (hence the - name). The FreeBSD IPsec network stack is - based on the KAME - implementation, which has support for both protocol - families, IPv4 and IPv6. + top of the Internet Protocol (IP) layer. + It allows two or more hosts to communicate in a secure manner. + The &os; IPsec network stack is based on the + KAME implementation, + which has support for both IPv4 and IPv6. IPsec ESP IPsec AH IPsec consists of two sub-protocols: Encapsulated Security Payload - ESP), protects the IP packet data from - third party interference, by encrypting the contents - using symmetric cryptography algorithms (like Blowfish, - 3DES). + ESP): this protocol + protects the IP packet data from third party interference + by encrypting the contents using symmetric cryptography + algorithms such as Blowfish and 3DES. - Authentication Header (AH), + Authentication Header + (AH): this protocol protects the IP packet header from third party - interference and spoofing, by computing a cryptographic + interference and spoofing by computing a cryptographic checksum and hashing the IP packet header fields with a secure hashing function. This is then followed by an additional header that contains the hash, to allow the information in the packet to be authenticated. ESP and AH can either be used together or separately, depending on the environment. VPN virtual private network VPN IPsec can either be used to directly encrypt the traffic - between two hosts (known as Transport - Mode); or to build virtual - tunnels between two subnets, which could be used for - secure communication between two corporate networks (known - as Tunnel Mode). The latter is more + between two hosts using Transport Mode or + to build virtual tunnels using + Tunnel Mode. The latter mode is more commonly known as a Virtual Private Network - (VPN). The &man.ipsec.4; manual page should be - consulted for detailed information on the IPsec subsystem in - FreeBSD. + (VPN). Consult &man.ipsec.4; + for detailed information on the IPsec subsystem in + &os;. - To add IPsec support to your kernel, add the following - options to your kernel configuration file: + To add IPsec support to the kernel, add the following + options to the custom kernel configuration file: kernel options IPSEC - -options IPSEC #IP security + options IPSEC #IP security device crypto kernel options IPSEC_DEBUG If IPsec debugging support is desired, the following kernel option should also be added: - -options IPSEC_DEBUG #debug for IP security + options IPSEC_DEBUG #debug for IP security - The Problem - - There is no standard for what constitutes a VPN. VPNs - can be implemented using a number of different technologies, - each of which have their own strengths and weaknesses. This - section presents a scenario, and the strategies used for - implementing a VPN for this scenario. - - - - The Scenario: Two networks, one home based and one - corporate based. Both are connected to the Internet, and - expected, via this <acronym>VPN</acronym> to behave as - one. + <acronym>VPN</acronym> Between a Home and Corporate + Network VPN creating - The premise is as follows: + There is no standard for what constitutes a + VPN. VPNs can be + implemented using a number of different technologies, each + of which has their own strengths and weaknesses. This + section presents the strategies used for implementing a + VPN for the following scenario: - You have at least two sites + There are at least two sites where each site is using + IP internally. - Both sites are using IP internally - - - - Both sites are connected to the Internet, through a - gateway that is running FreeBSD. + Both sites are connected to the Internet through a + gateway that is running &os;. The gateway on each network has at least one public IP address. The internal addresses of the two networks can be - public or private IP addresses, it does not matter. - They just may not collide; e.g.: may not both use + either public or private IP addresses. However, the + address space must not collide. For example, both + networks cannot use 192.168.1.x. - - - + + Tom Rhodes
trhodes@FreeBSD.org
 Written by - + Configuring IPsec on &os; - To begin, the + To begin, security/ipsec-tools - must be installed from the Ports Collection. This third - party software package provides a number of applications - which will help support the configuration. + must be installed from the Ports Collection. This software + provides a number of applications which support the + configuration. The next requirement is to create two &man.gif.4; pseudo-devices which will be used to tunnel packets and allow both networks to communicate properly. As root, run the following commands, - replacing the internal and - external items with the real - internal and external gateways: + replacing internal and + external with the real IP + addresses of the internal and external interfaces of the two + gateways: &prompt.root; ifconfig gif0 create &prompt.root; ifconfig gif0 internal1 internal2 &prompt.root; ifconfig gif0 tunnel external1 external2 - For example, the corporate LAN's - public IP is - 172.16.5.4 having a private - IP of - 10.246.38.1. The home - LAN's public IP is - 192.168.1.12 with an internal - private IP of - 10.0.0.5. + In this example, the corporate LAN's + external IP address is 172.16.5.4 and its internal + IP address is 10.246.38.1. The home + LAN's external IP + address is 192.168.1.12 and its + internal private IP address is 10.0.0.5. - This may seem confusing, so review the following example - output from the &man.ifconfig.8; command: + If this is confusing, review the following example output + from &man.ifconfig.8;: Gateway 1: gif0: flags=8051 mtu 1280 tunnel inet 172.16.5.4 --> 192.168.1.12 inet6 fe80::2e0:81ff:fe02:5881%gif0 prefixlen 64 scopeid 0x6 inet 10.246.38.1 --> 10.0.0.5 netmask 0xffffff00 Gateway 2: gif0: flags=8051 mtu 1280 tunnel inet 192.168.1.12 --> 172.16.5.4 inet 10.0.0.5 --> 10.246.38.1 netmask 0xffffff00 inet6 fe80::250:bfff:fe3a:c1f%gif0 prefixlen 64 scopeid 0x4 - Once complete, both private IPs - should be reachable using the &man.ping.8; command like - the following output suggests: + Once complete, both internal IP + addresses should be reachable using &man.ping.8;: priv-net# ping 10.0.0.5 PING 10.0.0.5 (10.0.0.5): 56 data bytes 64 bytes from 10.0.0.5: icmp_seq=0 ttl=64 time=42.786 ms 64 bytes from 10.0.0.5: icmp_seq=1 ttl=64 time=19.255 ms 64 bytes from 10.0.0.5: icmp_seq=2 ttl=64 time=20.440 ms 64 bytes from 10.0.0.5: icmp_seq=3 ttl=64 time=21.036 ms --- 10.0.0.5 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 19.255/25.879/42.786/9.782 ms corp-net# ping 10.246.38.1 PING 10.246.38.1 (10.246.38.1): 56 data bytes 64 bytes from 10.246.38.1: icmp_seq=0 ttl=64 time=28.106 ms 64 bytes from 10.246.38.1: icmp_seq=1 ttl=64 time=42.917 ms 64 bytes from 10.246.38.1: icmp_seq=2 ttl=64 time=127.525 ms 64 bytes from 10.246.38.1: icmp_seq=3 ttl=64 time=119.896 ms 64 bytes from 10.246.38.1: icmp_seq=4 ttl=64 time=154.524 ms --- 10.246.38.1 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 28.106/94.594/154.524/49.814 ms As expected, both sides have the ability to send and receive ICMP packets from the privately configured addresses. Next, both gateways must be told how to route packets in order to correctly send traffic from either network. The following command will achieve this goal: &prompt.root; corp-net# route add 10.0.0.0 10.0.0.5 255.255.255.0 &prompt.root; corp-net# route add net 10.0.0.0: gateway 10.0.0.5 &prompt.root; priv-net# route add 10.246.38.0 10.246.38.1 255.255.255.0 &prompt.root; priv-net# route add host 10.246.38.0: gateway 10.246.38.1 At this point, internal machines should be reachable from each gateway as well as from machines behind the - gateways. This is easily determined from the following - example: + gateways. Again, use &man.ping.8; to confirm: corp-net# ping 10.0.0.8 PING 10.0.0.8 (10.0.0.8): 56 data bytes 64 bytes from 10.0.0.8: icmp_seq=0 ttl=63 time=92.391 ms 64 bytes from 10.0.0.8: icmp_seq=1 ttl=63 time=21.870 ms 64 bytes from 10.0.0.8: icmp_seq=2 ttl=63 time=198.022 ms 64 bytes from 10.0.0.8: icmp_seq=3 ttl=63 time=22.241 ms 64 bytes from 10.0.0.8: icmp_seq=4 ttl=63 time=174.705 ms --- 10.0.0.8 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 21.870/101.846/198.022/74.001 ms priv-net# ping 10.246.38.107 PING 10.246.38.1 (10.246.38.107): 56 data bytes 64 bytes from 10.246.38.107: icmp_seq=0 ttl=64 time=53.491 ms 64 bytes from 10.246.38.107: icmp_seq=1 ttl=64 time=23.395 ms 64 bytes from 10.246.38.107: icmp_seq=2 ttl=64 time=23.865 ms 64 bytes from 10.246.38.107: icmp_seq=3 ttl=64 time=21.145 ms 64 bytes from 10.246.38.107: icmp_seq=4 ttl=64 time=36.708 ms --- 10.246.38.107 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 21.145/31.721/53.491/12.179 ms - Setting up the tunnels is the easy part. Configuring - a secure link is a much more in depth process. The - following configuration uses pre-shared - (PSK) RSA keys. Aside - from the IP addresses, both - /usr/local/etc/racoon/racoon.conf files - will be identical and look similar to + Setting up the tunnels is the easy part. Configuring a + secure link is a more in depth process. The following + configuration uses pre-shared (PSK) + RSA keys. Other than the + IP addresses, the + /usr/local/etc/racoon/racoon.conf on + both gateways will be identical and look similar to: path pre_shared_key "/usr/local/etc/racoon/psk.txt"; #location of pre-shared key file log debug; #log verbosity setting: set to 'notify' when testing and debugging is complete padding # options are not to be changed { maximum_length 20; randomize off; strict_check off; exclusive_tail off; } timer # timing options. change as needed { counter 5; interval 20 sec; persend 1; # natt_keepalive 15 sec; phase1 30 sec; phase2 15 sec; } listen # address [port] that racoon will listening on { isakmp 172.16.5.4 [500]; isakmp_natt 172.16.5.4 [4500]; } remote 192.168.1.12 [500] { exchange_mode main,aggressive; doi ipsec_doi; situation identity_only; my_identifier address 172.16.5.4; peers_identifier address 192.168.1.12; lifetime time 8 hour; passive off; proposal_check obey; # nat_traversal off; generate_policy off; proposal { encryption_algorithm blowfish; hash_algorithm md5; authentication_method pre_shared_key; lifetime time 30 sec; dh_group 1; } } sainfo (address 10.246.38.0/24 any address 10.0.0.0/24 any) # address $network/$netmask $type address $network/$netmask $type ( $type being any or esp) { # $network must be the two internal networks you are joining. pfs_group 1; lifetime time 36000 sec; encryption_algorithm blowfish,3des,des; authentication_algorithm hmac_md5,hmac_sha1; compression_algorithm deflate; } - Explaining every available option, along with those - listed in these examples is beyond the scope of this - document. There is plenty of relevant information in the - racoon configuration manual - page. - - The SPD policies need to be - configured so &os; and racoon is - able to encrypt and decrypt network traffic between - hosts. - - This task may be undertaken with a simple shell script - similar to the following which is on the corporate gateway. - This file will be used during system initialization and - should be saved as + For descriptions of each available option, refer to the + manual page for racoon.conf. + + The Security Policy Database (SPD) + needs to be configured so that &os; and + racoon are able to encrypt and + decrypt network traffic between the hosts. + + This can be achieved with a shell script, similar to the + following, on the corporate gateway. This file will be used + during system initialization and should be saved as /usr/local/etc/racoon/setkey.conf. flush; spdflush; # To the home network spdadd 10.246.38.0/24 10.0.0.0/24 any -P out ipsec esp/tunnel/172.16.5.4-192.168.1.12/use; spdadd 10.0.0.0/24 10.246.38.0/24 any -P in ipsec esp/tunnel/192.168.1.12-172.16.5.4/use; Once in place, racoon may be started on both gateways using the following command: &prompt.root; /usr/local/sbin/racoon -F -f /usr/local/etc/racoon/racoon.conf -l /var/log/racoon.log The output should be similar to the following: corp-net# /usr/local/sbin/racoon -F -f /usr/local/etc/racoon/racoon.conf Foreground mode. 2006-01-30 01:35:47: INFO: begin Identity Protection mode. 2006-01-30 01:35:48: INFO: received Vendor ID: KAME/racoon 2006-01-30 01:35:55: INFO: received Vendor ID: KAME/racoon 2006-01-30 01:36:04: INFO: ISAKMP-SA established 172.16.5.4[500]-192.168.1.12[500] spi:623b9b3bd2492452:7deab82d54ff704a 2006-01-30 01:36:05: INFO: initiate new phase 2 negotiation: 172.16.5.4[0]192.168.1.12[0] 2006-01-30 01:36:09: INFO: IPsec-SA established: ESP/Tunnel 192.168.1.12[0]->172.16.5.4[0] spi=28496098(0x1b2d0e2) 2006-01-30 01:36:09: INFO: IPsec-SA established: ESP/Tunnel 172.16.5.4[0]->192.168.1.12[0] spi=47784998(0x2d92426) 2006-01-30 01:36:13: INFO: respond new phase 2 negotiation: 172.16.5.4[0]192.168.1.12[0] 2006-01-30 01:36:18: INFO: IPsec-SA established: ESP/Tunnel 192.168.1.12[0]->172.16.5.4[0] spi=124397467(0x76a279b) 2006-01-30 01:36:18: INFO: IPsec-SA established: ESP/Tunnel 172.16.5.4[0]->192.168.1.12[0] spi=175852902(0xa7b4d66) To ensure the tunnel is working properly, switch to another console and use &man.tcpdump.1; to view network traffic using the following command. Replace em0 with the network interface card as - required. + required: &prompt.root; tcpdump -i em0 host 172.16.5.4 and dst 192.168.1.12 Data similar to the following should appear on the - console. If not, there is an issue, and debugging the + console. If not, there is an issue and debugging the returned data will be required. 01:47:32.021683 IP corporatenetwork.com > 192.168.1.12.privatenetwork.com: ESP(spi=0x02acbf9f,seq=0xa) 01:47:33.022442 IP corporatenetwork.com > 192.168.1.12.privatenetwork.com: ESP(spi=0x02acbf9f,seq=0xb) 01:47:34.024218 IP corporatenetwork.com > 192.168.1.12.privatenetwork.com: ESP(spi=0x02acbf9f,seq=0xc) At this point, both networks should be available and seem to be part of the same network. Most likely both - networks are protected by a firewall, as they should be. To - allow traffic to flow between them, rules need to be added - to pass packets back and forth. For the &man.ipfw.8; - firewall, add the following lines to the firewall - configuration file: + networks are protected by a firewall. To allow traffic to + flow between them, rules need to be added to pass packets. + For the &man.ipfw.8; firewall, add the following lines to the + firewall configuration file: ipfw add 00201 allow log esp from any to any ipfw add 00202 allow log ah from any to any ipfw add 00203 allow log ipencap from any to any ipfw add 00204 allow log udp from any 500 to any The rule numbers may need to be altered depending on the current host configuration. For users of &man.pf.4; or &man.ipf.8;, the following rules should do the trick: pass in quick proto esp from any to any pass in quick proto ah from any to any pass in quick proto ipencap from any to any pass in quick proto udp from any port = 500 to any port = 500 pass in quick on gif0 from any to any pass out quick proto esp from any to any pass out quick proto ah from any to any pass out quick proto ipencap from any to any pass out quick proto udp from any port = 500 to any port = 500 pass out quick on gif0 from any to any Finally, to allow the machine to start support for the VPN during system initialization, add the following lines to /etc/rc.conf: ipsec_enable="YES" ipsec_program="/usr/local/sbin/setkey" ipsec_file="/usr/local/etc/racoon/setkey.conf" # allows setting up spd policies on boot racoon_enable="yes" - + + Chern Lee Contributed by OpenSSH OpenSSH security OpenSSH OpenSSH is a set of network connectivity tools used to access remote machines securely. - It can be used as a direct replacement for - rlogin, rsh, - rcp, and telnet. Additionally, TCP/IP connections can be tunneled/forwarded - securely through SSH. OpenSSH - encrypts all traffic to effectively eliminate eavesdropping, - connection hijacking, and other network-level attacks. + securely through SSH connections. + OpenSSH encrypts all traffic to + effectively eliminate eavesdropping, connection hijacking, and + other network-level attacks. OpenSSH is maintained by the - OpenBSD project, and is based upon SSH v1.2.12 with all the - recent bug fixes and updates. It is compatible with both SSH - protocols 1 and 2. + OpenBSD project and is installed by default in &os;. It is + compatible with both SSH version 1 and 2 + protocols. - Advantages of Using OpenSSH - - Normally, when using &man.telnet.1; or &man.rlogin.1;, - data is sent over the network in a clear, un-encrypted form. - Network sniffers anywhere in between the client and server - can steal your user/password information or data transferred - in your session. OpenSSH offers - a variety of authentication and encryption methods to - prevent this from happening. + Advantages of Using + <application>OpenSSH</application> + + When data is sent over the network in an unencrypted form, + network sniffers anywhere in between the client and server + can steal user/password information or data transferred + during the session. OpenSSH offers + a variety of authentication and encryption methods to prevent + this from happening. - Enabling <application>sshd</application> + Enabling The SSH Server OpenSSH enabling - The sshd is an option - presented during a Standard install of - &os;. To see if sshd is enabled, - check the rc.conf file for: + To see if &man.sshd.8; is enabled, check + /etc/rc.conf for this line: sshd_enable="YES" - This will load &man.sshd.8;, the daemon program for - OpenSSH, the next time your - system initializes. Alternatively, it is possible to use - &man.service.8; to - start OpenSSH: + This will start &man.sshd.8;, the daemon program for + OpenSSH, the next time the system + initializes. Alternatively, it is possible to use + &man.service.8; to start OpenSSH + now: &prompt.root; service sshd start - SSH Client + The SSH Client OpenSSH client - The &man.ssh.1; utility works similarly to - &man.rlogin.1;. + To use &man.ssh.1; to connect to a system running + &man.sshd.8;, specify the username and host to log + into: &prompt.root; ssh user@example.com Host key not found from the list of known hosts. Are you sure you want to continue connecting (yes/no)? yes Host 'example.com' added to the list of known hosts. user@example.com's password: ******* - The login will continue just as it would have if a - session was created using rlogin or - telnet. SSH utilizes a key fingerprint - system for verifying the authenticity of the server when the - client connects. The user is prompted to enter - yes only when connecting for the first - time. Future attempts to login are all verified against the - saved fingerprint key. The SSH client will alert you if the - saved fingerprint differs from the received fingerprint on - future login attempts. The fingerprints are saved in - ~/.ssh/known_hosts, or - ~/.ssh/known_hosts2 for SSH v2 - fingerprints. - - By default, recent versions of the - OpenSSH servers only accept SSH - v2 connections. The client will use version 2 if possible - and will fall back to version 1. The client can also be - forced to use one or the other by passing it the - or for version 1 or - version 2, respectively. The version 1 compatibility is + SSH utilizes a key fingerprint system + to verify the authenticity of the server when the client + connects. The user is prompted to type + yes when connecting for the first time. + Future attempts to login are verified against the saved + fingerprint key and the &man.ssh.1; client will display an + alert if the saved fingerprint differs from the received + fingerprint on future login attempts. The fingerprints are + saved in ~/.ssh/known_hosts. + + By default, recent versions of &man.sshd.8; only accept + SSH v2 connections. The client will use + version 2 if possible and will fall back to version 1. The + client can also be forced to use one or the other by passing + it the or for version + 1 or version 2, respectively. The version 1 compatibility is maintained in the client for backwards compatibility with older versions. Secure Copy OpenSSH secure copy - scp + &man.scp.1; - The &man.scp.1; command works similarly to &man.rcp.1;; - it copies a file to or from a remote machine, except in a - secure fashion. + Use &man.scp.1; to copy a file to or from a remote machine + in a secure fashion. &prompt.root; scp user@example.com:/COPYRIGHT COPYRIGHT user@example.com's password: ******* COPYRIGHT 100% |*****************************| 4735 00:00 &prompt.root; Since the fingerprint was already saved for this host in the previous example, it is verified when using &man.scp.1; here. The arguments passed to &man.scp.1; are similar to - &man.cp.1;, with the file or files in the first argument, - and the destination in the second. Since the file is - fetched over the network, through SSH, one or more of the - file arguments takes on the form + &man.cp.1;, with the file or files to copy in the first + argument, and the destination in the second. Since the file + is fetched over the network, through an + SSH, connection, one or more of the file + arguments takes the form . Configuration OpenSSH configuration The system-wide configuration files for both the OpenSSH daemon and client reside - within the /etc/ssh - directory. + in /etc/ssh. ssh_config configures the client settings, while sshd_config configures - the daemon. - - Additionally, the - (/usr/sbin/sshd by default), and - rc.conf - options can provide more levels of configuration. + the daemon. Each file has its own manual page which describes + the available configuration options. - <application>ssh-keygen</application> + &man.ssh-keygen.1; - Instead of using passwords, &man.ssh-keygen.1; can - be used to generate DSA or RSA keys to authenticate a - user: + Instead of using passwords, &man.ssh-keygen.1; can be used + to generate DSA or RSA + keys to authenticate a user: &prompt.user; ssh-keygen -t dsa Generating public/private dsa key pair. Enter file in which to save the key (/home/user/.ssh/id_dsa): Created directory '/home/user/.ssh'. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/user/.ssh/id_dsa. Your public key has been saved in /home/user/.ssh/id_dsa.pub. The key fingerprint is: bb:48:db:f2:93:57:80:b6:aa:bc:f5:d5:ba:8f:79:17 user@host.example.com &man.ssh-keygen.1; will create a public and private key pair for use in authentication. The private key is stored in ~/.ssh/id_dsa or ~/.ssh/id_rsa, whereas the public key is stored in ~/.ssh/id_dsa.pub or - ~/.ssh/id_rsa.pub, respectively for + ~/.ssh/id_rsa.pub, respectively for the DSA and RSA key types. The public key must be placed in the ~/.ssh/authorized_keys file of the remote machine for both RSA or DSA keys in order for the setup to work. - This will allow connection to the remote machine based - upon SSH keys instead of passwords. + This setup allows connections to the remote machine based + upon SSH keys instead of passwords. + + + Many users believe that keys are secure by design and + will use a key without a passphrase. This is + dangerous behavior and the method + an administrator may use to verify keys have a passphrase + is to view the key manually. If the private key file + contains the word ENCRYPTED the key + owner is using a passphrase. While it may still be a weak + passphrase, at least if the system is compromised, access + to other sites will still require some level of password + guessing. In addition, to better secure end users, the + from may be placed in the public key + file. For example, adding + from="192.168.10.5 in the front of + ssh-rsa or rsa-dsa + prefix will only allow that specific user to login from + that host IP. + If a passphrase is used in &man.ssh-keygen.1;, the user - will be prompted for a password each time in order to use + will be prompted for the passphrase each time in order to use the private key. &man.ssh-agent.1; can alleviate the strain of repeatedly entering long passphrases, and is explored in - the section - below. + . - The various options and files can be different - according to the OpenSSH - version you have on your system; to avoid problems you - should consult the &man.ssh-keygen.1; manual page. + The various options and files can be different according + to the OpenSSH version. To avoid + problems, consult &man.ssh-keygen.1;. - <application>ssh-agent</application> and <application>ssh-add</application> - - The &man.ssh-agent.1; and &man.ssh-add.1; utilities - provide methods for SSH keys to - be loaded into memory for use, without needing to type the - passphrase each time. - - The &man.ssh-agent.1; utility will handle the - authentication using the private key(s) that are loaded into - it. &man.ssh-agent.1; should be used to launch another - application. At the most basic level, it could spawn a - shell or at a more advanced level, a window manager. - - To use &man.ssh-agent.1; in a shell, first it will need - to be spawned with a shell as an argument. Secondly, the - identity needs to be added by running &man.ssh-add.1; and - providing it the passphrase for the private key. Once these - steps have been completed the user will be able to - &man.ssh.1; to any host that has the corresponding public - key installed. For example: + Using SSH Agent To Cache Keys + + To load SSH keys into memory for use, + without needing to type the passphrase each time, use + &man.ssh-agent.1; and &man.ssh-add.1;. + + Authentication is handled by &man.ssh-agent.1;, using the + private key(s) that are loaded into it. Then, + &man.ssh-agent.1; should be used to launch another + application. At the most basic level, it could spawn a shell + or a window manager. + + To use &man.ssh-agent.1; in a shell, start it with a shell + as an argument. Next, add the identity by running + &man.ssh-add.1; and providing it the passphrase for the + private key. Once these steps have been completed, the user + will be able to &man.ssh.1; to any host that has the + corresponding public key installed. For example: &prompt.user; ssh-agent csh &prompt.user; ssh-add Enter passphrase for /home/user/.ssh/id_dsa: Identity added: /home/user/.ssh/id_dsa (/home/user/.ssh/id_dsa) &prompt.user; - To use &man.ssh-agent.1; in X11, a call to - &man.ssh-agent.1; will need to be placed in - ~/.xinitrc. This will provide the - &man.ssh-agent.1; services to all programs launched in X11. - An example ~/.xinitrc file might look - like this: + To use &man.ssh-agent.1; in + &xorg;, a call to &man.ssh-agent.1; + needs to be placed in ~/.xinitrc. This + provides the &man.ssh-agent.1; services to all programs + launched in &xorg;. An example + ~/.xinitrc file might look like + this: exec ssh-agent startxfce4 - This would launch &man.ssh-agent.1;, which would in turn - launch XFCE, every time X11 - starts. Then once that is done and X11 has been restarted so - that the changes can take effect, simply run &man.ssh-add.1; - to load all of your SSH keys. + This launches &man.ssh-agent.1;, which in turn launches + XFCE, every time + &xorg; starts. Once + &xorg; has been restarted so that + the changes can take effect, run &man.ssh-add.1; to load all + of the SSH keys. - SSH Tunneling + <acronym>SSH</acronym> Tunneling OpenSSH tunneling OpenSSH has the ability to create a tunnel to encapsulate another protocol in an encrypted session. The following command tells &man.ssh.1; to create a - tunnel for telnet: + tunnel for &man.telnet.1;: &prompt.user; ssh -2 -N -f -L 5023:localhost:23 user@foo.example.com &prompt.user; - The ssh command is used with the - following options: + This example uses the following options: - Forces ssh to use version 2 of - the protocol. (Do not use if you are working with - older SSH servers) + Forces &man.ssh.1; to use version 2 to connect to + the server. Indicates no command, or tunnel only. If omitted, - ssh would initiate a normal - session. + &man.ssh.1; initiates a normal session. - Forces ssh to run in the - background. + Forces &man.ssh.1; to run in the background. Indicates a local tunnel in localport:remotehost:remoteport - fashion. + format. - The remote SSH server. + The login name to use on the specified remote + SSH server. - An SSH tunnel works by creating a listen socket on - localhost on the specified port. It then - forwards any connection received on the local host/port via - the SSH connection to the specified remote host and - port. + An SSH tunnel works by creating a + listen socket on localhost on the specified + port. It then forwards any connections received on the local + host/port via the SSH connection to the + specified remote host and port. In the example, port 5023 on - localhost is being forwarded to port + localhost is forwarded to port 23 on localhost of the remote machine. Since 23 - is telnet, this would create a - secure telnet session through an - SSH tunnel. + is used by &man.telnet.1;, this creates an encrypted + &man.telnet.1; session through an + SSH tunnel. This can be used to wrap any number of insecure TCP - protocols such as SMTP, POP3, FTP, etc. + protocols such as SMTP, POP3, and FTP. - Using SSH to Create a Secure Tunnel for SMTP + Using &man.ssh.1; to Create a Secure Tunnel + for SMTP &prompt.user; ssh -2 -N -f -L 5025:localhost:25 user@mailserver.example.com user@mailserver.example.com's password: ***** &prompt.user; telnet localhost 5025 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 mailserver.example.com ESMTP - This can be used in conjunction with an - &man.ssh-keygen.1; and additional user accounts to create - a more seamless/hassle-free SSH tunneling environment. - Keys can be used in place of typing a password, and the - tunnels can be run as a separate user. + This can be used in conjunction with &man.ssh-keygen.1; + and additional user accounts to create a more seamless + SSH tunneling environment. Keys can be + used in place of typing a password, and the tunnels can be + run as a separate user. - Practical SSH Tunneling Examples + Practical <acronym>SSH</acronym> Tunneling + Examples Secure Access of a POP3 Server - At work, there is an SSH server that accepts - connections from the outside. On the same office - network resides a mail server running a POP3 server. - The network, or network path between your home and - office may or may not be completely trustable. Because - of this, you need to check your e-mail in a secure - manner. The solution is to create an SSH connection to - your office's SSH server, and tunnel through to the mail - server. + In this example, there is an SSH + server that accepts connections from the outside. On the + same network resides a mail server running a POP3 server. + To check email in a secure manner, create an + SSH connection to the + SSH server, and tunnel through to the + mail server. &prompt.user; ssh -2 -N -f -L 2110:mail.example.com:110 user@ssh-server.example.com user@ssh-server.example.com's password: ****** - When the tunnel is up and running, you can point - your mail client to send POP3 requests to - - localhost port 2110. A connection here - will be forwarded securely across the tunnel to + Once the tunnel is up and running, point the email + client to send POP3 requests to localhost + on port 2110. This connection will be forwarded securely + across the tunnel to mail.example.com. Bypassing a Draconian Firewall - Some network administrators impose extremely - draconian firewall rules, filtering not only incoming - connections, but outgoing connections. You may be only - given access to contact remote machines on ports 22 and - 80 for SSH and web surfing. - - You may wish to access another (perhaps non-work - related) service, such as an Ogg Vorbis server to stream - music. If this Ogg Vorbis server is streaming on some - other port than 22 or 80, you will not be able to access - it. + Some network administrators impose firewall rules + which filter both incoming and outgoing connections. For + example, it might limit access from remote machines to + ports 22 and 80 to only allow &man.ssh.1; and web surfing. + This prevents access to any other service which uses a + port other than 22 or 80. - The solution is to create an SSH connection to a - machine outside of your network's firewall, and use it - to tunnel to the Ogg Vorbis server. + The solution is to create an SSH + connection to a machine outside of the network's firewall + and use it to tunnel to the desired service. &prompt.user; ssh -2 -N -f -L 8888:music.example.com:8000 user@unfirewalled-system.example.org user@unfirewalled-system.example.org's password: ******* - Your streaming client can now be pointed to - localhost port 8888, which will be - forwarded over to music.example.com - port 8000, successfully evading the firewall. + In this example, a streaming Ogg Vorbis client can now + be pointed to localhost port 8888, which + will be forwarded over to + music.example.com on port 8000, + successfully bypassing the firewall. The <varname>AllowUsers</varname> Option It is often a good idea to limit which users can log in - and from where. The AllowUsers option is - a good way to accomplish this. For example, to only allow - the root user to log in from - 192.168.1.32, something like - this would be appropriate in the - /etc/ssh/sshd_config file: + and from where using AllowUsers. For + example, to only allow root to log in + from 192.168.1.32, add this + line to /etc/ssh/sshd_config: AllowUsers root@192.168.1.32 - To allow the user admin to log in - from anywhere, just list the username by itself: + To allow admin to log in from + anywhere, list that username by itself: AllowUsers admin Multiple users should be listed on the same line, like so: AllowUsers root@192.168.1.32 admin - It is important that you list each user that needs to - log in to this machine; otherwise they will be locked - out. + It is important to list each user that needs to log into + this machine; otherwise, they will be locked out. After making changes to - /etc/ssh/sshd_config you must tell - &man.sshd.8; to reload its config files, by running: + /etc/ssh/sshd_config, tell &man.sshd.8; + to reload its configuration file by running: &prompt.root; service sshd reload Further Reading - OpenSSH + The OpenSSH + website. - &man.ssh.1; &man.scp.1; &man.ssh-keygen.1; - &man.ssh-agent.1; &man.ssh-add.1; &man.ssh.config.5; + &man.ssh.1;, &man.scp.1;, &man.ssh-keygen.1;, + &man.ssh-agent.1;, &man.ssh-add.1;, and &man.ssh.config.5; for + client options. - &man.sshd.8; &man.sftp-server.8; - &man.sshd.config.5; + &man.sshd.8;, &man.sftp-server.8;, and &man.sshd.config.5; + for server options. Tom Rhodes Contributed by - File System Access Control Lists + <title>Filesystem Access Control Lists (<acronym>ACL</acronym>s) ACL - In conjunction with file system enhancements like - snapshots, FreeBSD offers the security of File System Access - Control Lists (ACLs). + Filesystem Access Control Lists (ACLs) + extend the standard &unix; permission model in a &posix;.1e + compatible way. This permits an administrator to make use of + and take advantage of a more sophisticated security + model. - Access Control Lists extend the standard &unix; permission - model in a highly compatible (&posix;.1e) way. This feature - permits an administrator to make use of and take advantage of - a more sophisticated security model. - - To enable ACL support for - UFS file systems, the following: + The &os; GENERIC kernel provides + ACL support for UFS file + systems. Users who prefer to compile a custom kernel must + include the following option in their custom kernel + configuration file: options UFS_ACL - must be compiled into the kernel. If this option has not - been compiled in, a warning message will be displayed when - attempting to mount a file system supporting - ACLs. This option is included in the - GENERIC kernel. ACLs - rely on extended attributes being enabled on the file system. - Extended attributes are natively supported in the next - generation &unix; file system, UFS2. + If this option is not compiled in, a warning message will be + displayed when attempting to mount a filesystem supporting + ACLs. ACLs rely on + extended attributes being enabled on the filesystem. Extended + attributes are natively supported in + UFS2. A higher level of administrative overhead is required to configure extended attributes on UFS1 than on UFS2. The performance of extended attributes on UFS2 is also substantially higher. As a result, UFS2 - is generally recommended in preference to - UFS1 for use with access control - lists. + is recommended for use with ACLs. ACLs are enabled by the mount-time administrative flag, , which may be added to /etc/fstab. The mount-time flag can also be automatically set in a persistent manner using &man.tunefs.8; to modify a superblock ACLs - flag in the file system header. In general, it is preferred + flag in the filesystem header. In general, it is preferred to use the superblock flag for several reasons: The mount-time ACLs flag cannot be - changed by a remount (&man.mount.8; ), - only by means of a complete &man.umount.8; and fresh - &man.mount.8;. This means that ACLs - cannot be enabled on the root file system after boot. It - also means that you cannot change the disposition of a - file system once it is in use. + changed by a remount using . It + requires a complete &man.umount.8; and fresh &man.mount.8;. + This means that ACLs cannot be enabled on + the root filesystem after boot. It also means that the + disposition of a filesystem cannot be changed once it is in + use. - Setting the superblock flag will cause the file system - to always be mounted with ACLs enabled + Setting the superblock flag will cause the filesystem + to always be mounted with ACLs enabled, even if there is not an fstab entry or if the devices re-order. This prevents accidental - mounting of the file system without - ACLs enabled, which can result in - ACLs being improperly enforced, and - hence security problems. + mounting of the filesystem without ACLs + enabled, which can result in the security problem of + ACLs being improperly enforced. - We may change the ACLs behavior to - allow the flag to be enabled without a complete fresh - &man.mount.8;, but we consider it desirable to discourage - accidental mounting without ACLs enabled, - because you can shoot your feet quite nastily if you enable - ACLs, then disable them, then re-enable - them without flushing the extended attributes. In general, - once you have enabled ACLs on a file - system, they should not be disabled, as the resulting file + It is desirable to discourage accidental mounting without + ACLs enabled, because nasty things can + happen if ACLs are enabled, then disabled, + then re-enabled without flushing the extended attributes. In + general, once ACLs are enabled on a + filesystem, they should not be disabled, as the resulting file protections may not be compatible with those intended by the users of the system, and re-enabling ACLs may re-attach the previous ACLs to files that have since had their permissions changed, resulting in - other unpredictable behavior. + unpredictable behavior. - File systems with ACLs enabled will + Filesystems with ACLs enabled will show a + (plus) sign in their permission settings when viewed. For example: drwx------ 2 robert robert 512 Dec 27 11:54 private drwxrwx---+ 2 robert robert 512 Dec 23 10:57 directory1 drwxrwx---+ 2 robert robert 512 Dec 22 10:20 directory2 drwxrwx---+ 2 robert robert 512 Dec 27 11:57 directory3 drwxr-xr-x 2 robert robert 512 Nov 10 11:54 public_html - Here we see that the + In this example, directory1, directory2, and - directory3 directories - are all taking advantage of ACLs. The - public_html directory + directory3 + are all taking advantage of ACLs, whereas + public_html is not. Making Use of <acronym>ACL</acronym>s - The file system ACLs can be viewed by - the &man.getfacl.1; utility. For instance, to view the - ACL settings on the - test file, one would use the - command: + Filesystem ACLs can be viewed using + &man.getfacl.1;. For instance, to view the + ACL settings on + test: &prompt.user; getfacl test #file:test #owner:1001 #group:1001 user::rw- group::r-- other::r-- To change the ACL settings on this - file, invoke the &man.setfacl.1; utility. Observe: + file, use &man.setfacl.1;: &prompt.user; setfacl -k test - The flag will remove all of the - currently defined ACLs from a file or - file system. The more preferable method would be to use + To remove all of the currently defined + ACLs from a file or filesystem, one can use + . However, the preferred method is to use as it leaves the basic fields required for ACLs to work. &prompt.user; setfacl -m u:trhodes:rwx,group:web:r--,o::--- test - In the aforementioned command, the - option was used to modify the default ACL - entries. Since there were no pre-defined entries, as they - were removed by the previous command, this will restore the - default options and assign the options listed. Take care to - notice that if you add a user or group which does not exist - on the system, an Invalid argument - error will be printed to - stdout. + In this example, is used to modify the + default ACL entries. Since there were no + pre-defined entries, as they were removed by the previous + command, it restores the default options and assign the + options listed. If a user or group is added which does not + exist on the system, an Invalid + argument error will be displayed. Tom Rhodes Contributed by Monitoring Third Party Security Issues - Portaudit + portaudit In recent years, the security world has made many improvements to how vulnerability assessment is handled. The threat of system intrusion increases as third party utilities are installed and configured for virtually any operating system available today. - Vulnerability assessment is a key factor in security, and - while &os; releases advisories for the base system, doing so + Vulnerability assessment is a key factor in security. + While &os; releases advisories for the base system, doing so for every third party utility is beyond the &os; Project's capability. There is a way to mitigate third party vulnerabilities and warn administrators of known security issues. A &os; add on utility known as - Portaudit exists solely for this + portaudit exists solely for this purpose. The ports-mgmt/portaudit - port polls a database, updated and maintained by the &os; - Security Team and ports developers, for known security + port polls a database, which is updated and maintained by the + &os; Security Team and ports developers, for known security issues. - To begin using Portaudit, one - must install it from the Ports Collection: + To install portaudit from the + Ports Collection: &prompt.root; cd /usr/ports/ports-mgmt/portaudit && make install clean - During the install process, the configuration files for + During the installation, the configuration files for &man.periodic.8; will be updated, permitting - Portaudit output in the daily - security runs. Ensure the daily security run emails, which + portaudit output in the daily + security runs. Ensure that the daily security run emails, which are sent to root's email account, are - being read. No more configuration will be required - here. + being read. No other configuration is required. After installation, an administrator can update the database and view known vulnerabilities in installed packages by invoking the following command: &prompt.root; portaudit -Fda - The database will automatically be updated during the - &man.periodic.8; run; thus, the previous command is - completely optional. It is only required for the following - examples. + The database is automatically updated during the + &man.periodic.8; run. The above command is optional and can + be used to manually update the database now. To audit the third party utilities installed as part of - the Ports Collection at anytime, an administrator need only - run the following command: + the Ports Collection at anytime, an administrator can run the + following command: &prompt.root; portaudit -a - Portaudit will produce - something like this for vulnerable packages: + portaudit will display messages + for any installed vulnerable packages: Affected package: cups-base-1.1.22.0_1 Type of problem: cups-base -- HPGL buffer overflow vulnerability. Reference: <http://www.FreeBSD.org/ports/portaudit/40a3bca2-6809-11d9-a9e7-0001020eed82.html> 1 problem(s) in your installed packages found. You are advised to update or deinstall the affected package(s) immediately. - By pointing a web browser to the URL - shown, an administrator may obtain more information about the - vulnerability in question. This will include versions - affected, by &os; Port version, along with other web sites - which may contain security advisories. + By pointing a web browser to the displayed + URL, an administrator may obtain more + information about the vulnerability. This will include the + versions affected, by &os; port version, along with other web + sites which may contain security advisories. - In short, Portaudit is a - powerful utility and extremely useful when coupled with the - Portupgrade port. + portaudit is a powerful utility + and is extremely useful when coupled with the + portmaster port. Tom Rhodes Contributed by &os; Security Advisories - FreeBSD Security Advisories + &os; Security Advisories Like many production quality operating systems, &os; publishes Security Advisories. These advisories are usually mailed to the security lists and noted in the Errata only after the appropriate releases have been - patched. This section will work to explain what an advisory - is, how to understand it, and what measures to take in order - to patch a system. + patched. This section explains what an advisory is, how to + understand it, and what measures to take in order to patch a + system. What Does an Advisory Look Like? - The &os; security advisories look similar to the one - below, taken from the &a.security-notifications.name; - mailing list. + &os; security advisories use the format seen in this + example: ============================================================================= FreeBSD-SA-XX:XX.UTIL Security Advisory The FreeBSD Project Topic: denial of service due to some problem Category: core Module: sys Announced: 2003-09-23 Credits: Person Affects: All releases of &os; &os; 4-STABLE prior to the correction date Corrected: 2003-09-23 16:42:59 UTC (RELENG_4, 4.9-PRERELEASE) 2003-09-23 20:08:42 UTC (RELENG_5_1, 5.1-RELEASE-p6) 2003-09-23 20:07:06 UTC (RELENG_5_0, 5.0-RELEASE-p15) 2003-09-23 16:44:58 UTC (RELENG_4_8, 4.8-RELEASE-p8) 2003-09-23 16:47:34 UTC (RELENG_4_7, 4.7-RELEASE-p18) 2003-09-23 16:49:46 UTC (RELENG_4_6, 4.6-RELEASE-p21) 2003-09-23 16:51:24 UTC (RELENG_4_5, 4.5-RELEASE-p33) 2003-09-23 16:52:45 UTC (RELENG_4_4, 4.4-RELEASE-p43) 2003-09-23 16:54:39 UTC (RELENG_4_3, 4.3-RELEASE-p39) CVE Name: CVE-XXXX-XXXX For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit http://www.FreeBSD.org/security/. I. Background II. Problem Description III. Impact IV. Workaround V. Solution VI. Correction details VII. References - The Topic field indicates exactly - what the problem is. It is basically an introduction to - the current security advisory and notes the utility with - the vulnerability. + The Topic field specifies the + problem. It provides an introduction to the security + advisory and notes the utility affected by the + vulnerability. The Category refers to the affected part of the system which may be one of core, contrib, or ports. The core category means that the vulnerability affects a core component of the &os; operating system. The contrib category means that the vulnerability affects software contributed to the &os; - Project, such as sendmail. - Finally the ports category indicates - that the vulnerability affects add on software available - as part of the Ports Collection. + Project, such as Sendmail. + The ports category indicates that the + vulnerability affects add on software available through + the Ports Collection. The Module field refers to the - component location, for instance sys. - In this example, we see that the module, - sys, is affected; therefore, this + component location. In this example, the + sys module is affected; therefore, this vulnerability affects a component used within the kernel. The Announced field reflects the - date said security advisory was published, or announced + date the security advisory was published, or announced to the world. This means that the security team has - verified that the problem does exist and that a patch - has been committed to the &os; source code - repository. + verified that the problem exists and that a patch has + been committed to the &os; source code repository. The Credits field gives credit to the individual or organization who noticed the vulnerability and reported it. The Affects field explains which releases of &os; are affected by this vulnerability. For the kernel, a quick look over the output from - ident on the affected files will help - in determining the revision. For ports, the version - number is listed after the port name in - /var/db/pkg. If - the system does not sync with the &os; - Subversion repository and rebuilt daily, - chances are that it is affected. + &man.ident.1; on the affected files will help in + determining the revision. For ports, the version number + is listed after the port name in /var/db/pkg. If the + system does not sync with the &os; Subversion repository + and is not rebuilt daily, chances are that it is + affected. The Corrected field indicates the date, time, time offset, and release that was corrected. Reserved for the identification information used to - look up vulnerabilities in the Common Vulnerabilities - Database system. + look up vulnerabilities in the Common Vulnerabilities + and Exposures database. The Background field gives - information on exactly what the affected utility is. - Most of the time this is why the utility exists in &os;, - what it is used for, and a bit of information on how the - utility came to be. + information about the affected utility. Most of the time + this is why the utility exists in &os;, what it is used + for, and a bit of information on how the utility came to + be. The Problem Description field explains the security hole in depth. This can include information on flawed code, or even how the utility - could be maliciously used to open a security - hole. + could be maliciously used to open a security hole. The Impact field describes what type of impact the problem could have on a system. For example, this could be anything from a denial of service attack, to extra privileges available to users, or even giving the attacker superuser access. The Workaround field offers a - feasible workaround to system administrators who may be - incapable of upgrading the system. This may be due to - time constraints, network availability, or a slew of - other reasons. Regardless, security should not be taken - lightly, and an affected system should either be patched - or the security hole workaround should be - implemented. + workaround to system administrators who cannot + upgrade the system due to time constraints, network + availability, or other reasons. Security should not be + taken lightly, and an affected system should either be + patched or the workaround implemented. The Solution field offers - instructions on patching the affected system. This is a + instructions for patching the affected system. This is a step by step tested and verified method for getting a system patched and working securely. The Correction Details field - displays the Subversion branch or release - name with the periods changed to underscore characters. - It also shows the revision number of the affected files - within each branch. + displays the Subversion branch or release name with the + periods changed to underscore characters. It also shows + the revision number of the affected files within each + branch. The References field usually offers sources of other information. This can include web URLs, books, mailing lists, and newsgroups. Tom Rhodes Contributed by Process Accounting Process Accounting Process accounting is a security method in which an - administrator may keep track of system resources used, + administrator may keep track of system resources used and their allocation among users, provide for system monitoring, and minimally track a user's commands. - This indeed has its own positive and negative points. One + This indeed has both positive and negative points. One of the positives is that an intrusion may be narrowed down to the point of entry. A negative is the amount of logs generated by process accounting, and the disk space they may - require. This section will walk an administrator through the + require. This section walks an administrator through the basics of process accounting. Enabling and Utilizing Process Accounting - Before making use of process accounting, it must be - enabled. To do this, execute the following commands: + Before using process accounting, it must be enabled using + the following commands: &prompt.root; touch /var/account/acct &prompt.root; accton /var/account/acct &prompt.root; echo 'accounting_enable="YES"' >> /etc/rc.conf - Once enabled, accounting will begin to track - CPU stats, commands, etc. All accounting - logs are in a non-human readable format and may be viewed - using the &man.sa.8; utility. If issued without any - options, sa will print information - relating to the number of per user calls, the total elapsed - time in minutes, total CPU and user time - in minutes, average number of I/O operations, etc. - - To view information about commands being issued, one - would use the &man.lastcomm.1; utility. The - lastcomm command may be used to print out - commands issued by users on specific &man.ttys.5;, for - example: + Once enabled, accounting will begin to track information + such as CPU statistics and executed + commands. All accounting logs are in a non-human readable + format which can be viewed using &man.sa.8;. If issued + without any options, &man.sa.8; prints information relating to + the number of per-user calls, the total elapsed time in + minutes, total CPU and user time in + minutes, and the average number of I/O operations. + + To view information about commands being issued, use + &man.lastcomm.1;. This command displays the commands issued + by users on specific &man.ttys.5;. For example, this command + prints out all known usage of &man.ls.1; by + trhodes on the ttyp1 + terminal: &prompt.root; lastcomm ls trhodes ttyp1 - Would print out all known usage of the - ls by trhodes on the - ttyp1 terminal. - Many other useful options exist and are explained in the - &man.lastcomm.1;, &man.acct.5; and &man.sa.8; manual - pages. + &man.lastcomm.1;, &man.acct.5;, and &man.sa.8;. + + + + + + Tom + Rhodes + Contributed by + + + + + Resource Limits + + + Resource limits + + + For years, &os; has used a resource limits + database controlled through a flat file, + /etc/login.conf. While it has + been discussed previously and is still supported, it + is not the most optimal method of controlling resources. + The flat file requires users to be divided into various + group labels known as classes, which require changes not + only to this flat file but also the password database. + Potentially a single, more constrained user would require + an additional label added, the resource database needs to be + built using cap_mkdb, edits made to + the /etc/master.passwd file. In + addition, the password database must be rebuilt using + pwd_mkdb. This multi-step process could be + very time consuming depending on how many users must be + singled out. + + A new command in &os;, &man.rctl.8;, allows for a more + fine grained method of controlling resources limits for + users. This command will support much more than users, + it will also set resource constraints on processes, jails, + and the original login class. These advanced features + provide administrators and users with methods to control + resources through the command line and set rules on + system initialization using a configuration + file. + + To enable this feature, add these lines to + GENERIC, or the custom kernel + configuration file, and rebuild.: + + options RACCT +options RCTL + + The entire system will need rebuilt. See , which will provide instructions for + the process. Once this is complete, the rctl + may be used to set rules for the system. + + Rule syntax is simple, controlled through the use of + a subject, a subject-id, + resource, and action. + Take the following example rule: + + user:trhodes:maxproc:deny=10/user + + This rule shows a basic premise of a rule, here the + subject is user and the subject-id + is trhodes. The maxproc is, of course, + max number of processes, which is considered the action. + The action here is set to deny, which blocks + any new processes from being created. In the previous example, + the user, trhodes will be constrained + to 10 (ten) processes and no greater. + Other actions are available and could be log to the console, + pass a notification to &man.devd.8;, or + send a sigterm to the process. + + Some care must be taken while adding rules. The one above + will unfortunately block my user from doing the most simple tasks + after I have logged in and executed a screen + session. When a resource limit has been hit, an error will + be printed, as in this example: + + &prompt.user; man test + /usr/bin/man: Cannot fork: Resource temporarily unavailable +eval: Cannot fork: Resource temporarily unavailable + + For another example, &man.rctl.8; can be used to prevent + a jail from exceeding a memory limit. This rule could be + written as: + + &prompt.root; rctl -a jail:httpd:memoryuse:deny=2G/jail + + Rules may also persist across reboots if they have been + added to /etc/rctl.conf file. The + format is a rule, without the preceding command. For example, + the previous rule could be added like the following: + + # Block jail from using more than 2G memory: +jail:httpd:memoryuse:deny=2G/jail + + To remove a rule, just ask rctl to + remove it from the list: + + &prompt.root; rctl -r user:trhodes:maxproc:deny=10/user + + The manual page shows a method for removing all rules; + however, if removing all rules for a single user is required, + this command may be issued: + + &prompt.root; rctl -r user:trhodes + + Many other resources exist which can be used to excert + additional control over various subjects. + See &man.rctl.8; to learn about them. + diff --git a/en_US.ISO8859-1/books/handbook/users/chapter.xml b/en_US.ISO8859-1/books/handbook/users/chapter.xml index c6be01a81e..4ac3616b48 100644 --- a/en_US.ISO8859-1/books/handbook/users/chapter.xml +++ b/en_US.ISO8859-1/books/handbook/users/chapter.xml @@ -1,1037 +1,1082 @@ Neil Blakey-Milner Contributed by Users and Basic Account Management Synopsis &os; allows multiple users to use the computer at the same time. While only one user can sit in front of the screen and use the keyboard at any one time, any number of users can log in to the system through the network. To use the system, every user must have a user account. After reading this chapter, you will know: The differences between the various user accounts on a &os; system. How to add and remove user accounts. How to change account details, such as the user's full name or preferred shell. How to set limits on a per-account basis to control the resources, such as memory and CPU time, that accounts and groups of accounts are allowed to access. How to use groups to make account management easier. Before reading this chapter, you should: Understand the basics of &unix; and &os;. Introduction Since all access to the &os; system is achieved via accounts and all processes are run by users, user and account management is important. Every account on a &os; system has certain information associated with it to identify the account. User name The user name is typed at the login: prompt. User names must be unique on the system as no two users can have the same user name. There are a number of rules for creating valid user names, documented in &man.passwd.5;. Typically user names consist of eight or fewer all lower case characters in order to maintain backwards compatibility with applications. Password Each account has an associated password. While the password can be blank, this is highly discouraged and every account should have a password. User ID (UID) The User ID (UID) is a number, traditionally from 0 to 65535 It is possible to use UIDs/GIDs as large as 4294967295, but such IDs can cause serious problems with software that makes assumptions about the values of IDs. , used to uniquely identify the user to the system. Internally, &os; uses the UID to identify users. Commands that allow a user name to be specified will first convert it to the UID. Though unlikely, it is possible for several accounts with different user names to share the same UID. As far as &os; is concerned, these accounts are one user. Group ID (GID) The Group ID (GID) is a number, traditionally from 0 to 65535, used to uniquely identify the primary group that the user belongs to. Groups are a mechanism for controlling access to resources based on a user's GID rather than their UID. This can significantly reduce the size of some configuration files. A user may also be a member of more than one group. Login class Login classes are an extension to the group mechanism that provide additional flexibility when tailoring the system to different users. Password change time By default &os; does not force users to change their passwords periodically. Password expiration can be enforced on a per-user basis, forcing some or all users to change their passwords after a certain amount of time has elapsed. Account expiry time By default &os; does not expire accounts. When creating accounts that need a limited lifespan, such as student accounts in a school, specify the account expiry date. After the expiry time has elapsed, the account cannot be used to log in to the system, although the account's directories and files will remain. User's full name The user name uniquely identifies the account to &os;, but does not necessarily reflect the user's real name. This information can be associated with the account. Home directory The home directory is the full path to a directory on the system. This is the user's starting directory when the user logs in. A common convention is to put all user home directories under /home/username or /usr/home/username. Each user stores their personal files and subdirectories in their own home directory. User shell The shell provides the default environment users use to interact with the system. There are many different kinds of shells, and experienced users will have their own preferences, which can be reflected in their account settings. There are three main types of accounts: the superuser, system accounts, and user accounts. The superuser account, usually called root, is used to manage the system with no limitations on privileges. System accounts are used to run services. User accounts are assigned to real people and are used to log in and use the system. The Superuser Account accounts superuser (root) The superuser account, usually called root, is used to perform system administration tasks and should not be used for day-to-day tasks like sending and receiving mail, general exploration of the system, or programming. This is because the superuser, unlike normal user accounts, can operate without limits, and misuse of the superuser account may result in spectacular disasters. User accounts are unable to destroy the system by mistake, so it is generally best to use normal user accounts whenever possible, unless extra privilege is required. Always double and triple-check any commands issued as the superuser, since an extra space or missing character can mean irreparable data loss. Always create a user account for the system administrator and use this account to log in to the system for general usage. This applies equally to multi-user or single-user systems. Later sections will discuss how to create additional accounts and how to change between the normal user and superuser. System Accounts accounts system System accounts are used to run services such as DNS, mail, and web servers. The reason for this is security; if all services ran as the superuser, they could act without restriction. accounts daemon accounts operator Examples of system accounts are daemon, operator, bind, news, and www. accounts nobody nobody is the generic unprivileged system account. However, the more services that use nobody, the more files and processes that user will become associated with, and hence the more privileged that user becomes. User Accounts accounts user User accounts are the primary means of access for real people to the system. User accounts insulate the user and the environment, preventing users from damaging the system or other users, and allowing users to customize their environment without affecting others. Every person accessing the system should have a unique user account. This allows the administrator to find out who is doing what, prevents users from clobbering each others' settings or reading each others' mail, and so forth. Each user can set up their own environment to accommodate their use of the system, by using alternate shells, editors, key bindings, and language. Modifying Accounts accounts modifying &os; provides a variety of different commands to manage user accounts. The most common commands are summarized below, followed by more detailed examples of their usage. Command Summary &man.adduser.8; The recommended command-line application for adding new users. &man.rmuser.8; The recommended command-line application for removing users. &man.chpass.1; A flexible tool for changing user database information. &man.passwd.1; The simple command-line tool to change user passwords. &man.pw.8; A powerful and flexible tool for modifying all aspects of user accounts. <command>adduser</command> accounts adding adduser /usr/share/skel skeleton directory &man.adduser.8; is a simple program for adding new users When a new user is added, this program automatically updates /etc/passwd and /etc/group. It also creates a home directory for the new user, copies in the default configuration files from /usr/share/skel, and can optionally mail the new user a welcome message. Adding a User on &os; &prompt.root; adduser Username: jru Full name: J. Random User Uid (Leave empty for default): Login group [jru]: Login group is jru. Invite jru into other groups? []: wheel Login class [default]: Shell (sh csh tcsh zsh nologin) [sh]: zsh Home directory [/home/jru]: Home directory permissions (Leave empty for default): Use password-based authentication? [yes]: Use an empty password? (yes/no) [no]: Use a random password? (yes/no) [no]: Enter password: Enter password again: Lock out the account after creation? [no]: Username : jru Password : **** Full Name : J. Random User Uid : 1001 Class : Groups : jru wheel Home : /home/jru Shell : /usr/local/bin/zsh Locked : no OK? (yes/no): yes adduser: INFO: Successfully added (jru) to the user database. Add another user? (yes/no): no Goodbye! &prompt.root; Since the password is not echoed when typed, be careful to not mistype the password when creating the user account. <command>rmuser</command> rmuser accounts removing To completely remove a user from the system use &man.rmuser.8;. This command performs the following steps: Removes the user's &man.crontab.1; entry if one exists. Removes any &man.at.1; jobs belonging to the user. Kills all processes owned by the user. Removes the user from the system's local password file. Removes the user's home directory, if it is owned by the user. Removes the incoming mail files belonging to the user from /var/mail. Removes all files owned by the user from temporary file storage areas such as /tmp. Finally, removes the username from all groups to which it belongs in /etc/group. If a group becomes empty and the group name is the same as the username, the group is removed. This complements the per-user unique groups created by &man.adduser.8;. &man.rmuser.8; cannot be used to remove superuser accounts since that is almost always an indication of massive destruction. By default, an interactive mode is used, as shown in the following example. <command>rmuser</command> Interactive Account Removal &prompt.root; rmuser jru Matching password entry: jru:*:1001:1001::0:0:J. Random User:/home/jru:/usr/local/bin/zsh Is this the entry you wish to remove? y Remove user's home directory (/home/jru)? y Updating password file, updating databases, done. Updating group file: trusted (removing group jru -- personal group is empty) done. Removing user's incoming mail file /var/mail/jru: done. Removing files belonging to jru from /tmp: done. Removing files belonging to jru from /var/tmp: done. Removing files belonging to jru from /var/tmp/vi.recover: done. &prompt.root; <command>chpass</command> chpass &man.chpass.1; can be used to change user database information such as passwords, shells, and personal information. Only the superuser can change other users' information and passwords with &man.chpass.1;. When passed no options, aside from an optional username, &man.chpass.1; displays an editor containing user information. When the user exists from the editor, the user database is updated with the new information. You will be asked for your password after exiting the editor if you are not the superuser. Interactive <command>chpass</command> by Superuser #Changing user database information for jru. Login: jru Password: * Uid [#]: 1001 Gid [# or name]: 1001 Change [month day year]: Expire [month day year]: Class: Home directory: /home/jru Shell: /usr/local/bin/zsh Full Name: J. Random User Office Location: Office Phone: Home Phone: Other information: A user can change only a small subset of this information, and only for their own user account. Interactive <command>chpass</command> by Normal User #Changing user database information for jru. Shell: /usr/local/bin/zsh Full Name: J. Random User Office Location: Office Phone: Home Phone: Other information: &man.chfn.1; and &man.chsh.1; are links to &man.chpass.1;, as are &man.ypchpass.1;, &man.ypchfn.1;, and &man.ypchsh.1;. NIS support is automatic, so specifying the yp before the command is not necessary. How to configure NIS is covered in . <command>passwd</command> passwd accounts changing password &man.passwd.1; is the usual way to change your own password as a user, or another user's password as the superuser. To prevent accidental or unauthorized changes, the user must enter their original password before a new password can be set. This is not the case when the superuser changes a user's password. Changing Your Password &prompt.user; passwd Changing local password for jru. Old password: New password: Retype new password: passwd: updating the database... passwd: done Changing Another User's Password as the Superuser &prompt.root; passwd jru Changing local password for jru. New password: Retype new password: passwd: updating the database... passwd: done As with &man.chpass.1;, &man.yppasswd.1; is a link to &man.passwd.1;, so NIS works with either command. <command>pw</command> pw &man.pw.8; is a command line utility to create, remove, modify, and display users and groups. It functions as a front end to the system user and group files. &man.pw.8; has a very powerful set of command line options that make it suitable for use in shell scripts, but new users may find it more complicated than the other commands presented in this section. Limiting Users limiting users accounts limiting &os; provides several methods for an administrator to limit the amount of system resources an individual may use. These limits are discussed in two sections: disk quotas and other resource limits. quotas limiting users quotas disk quotas Disk quotas limit the amount of disk space available to users and provide a way to quickly check that usage without calculating it every time. Quotas are discussed in . The other resource limits include ways to limit the amount of CPU, memory, and other resources a user may consume. These are defined using login classes and are discussed here. /etc/login.conf Login classes are defined in /etc/login.conf and are described in detail in &man.login.conf.5;. Each user account is assigned to a login class, default by default, and each login class has a set of login capabilities associated with it. A login capability is a name=value pair, where name is a well-known identifier and value is an arbitrary string which is processed accordingly depending on the name. Setting up login classes and capabilities is rather straightforward and is also described in &man.login.conf.5;. &os; does not normally read the configuration in /etc/login.conf directly, but instead reads the /etc/login.conf.db database which provides faster lookups. Whenever /etc/login.conf is edited, the /etc/login.conf.db must be updated by executing the following command: &prompt.root; cap_mkdb /etc/login.conf Resource limits differ from the default login capabilities in two ways. First, for every limit, there is a soft (current) and hard limit. A soft limit may be adjusted by the user or application, but may not be set higher than the hard limit. The hard limit may be lowered by the user, but can only be raised by the superuser. Second, most resource limits apply per process to a specific user, not to the user as a whole. These differences are mandated by the specific handling of the limits, not by the implementation of the login capability framework. Below are the most commonly used resource limits. The rest of the limits, along with all the other login capabilities, can be found in &man.login.conf.5;. coredumpsize coredumpsize limiting users coredumpsize The limit on the size of a core file generated by a program is subordinate to other limits on disk usage, such as filesize, or disk quotas. This limit is often used as a less-severe method of controlling disk space consumption. Since users do not generate core files themselves, and often do not delete them, setting this may save them from running out of disk space should a large program crash. cputime cputime limiting users cputime The maximum amount of CPU time a user's process may consume. Offending processes will be killed by the kernel. This is a limit on CPU time consumed, not percentage of the CPU as displayed in some fields by &man.top.1; and &man.ps.1;. filesize filesize limiting users filesize The maximum size of a file the user may own. Unlike disk quotas, this limit is enforced on individual files, not the set of all files a user owns. maxproc maxproc limiting users maxproc The maximum number of processes a user can run. This includes foreground and background processes. This limit may not be larger than the system limit specified by the kern.maxproc &man.sysctl.8;. Setting this limit too small may hinder a user's productivity as it is often useful to be logged in multiple times or to execute pipelines. Some tasks, such as compiling a large program, spawn multiple processes and other intermediate preprocessors. memorylocked memorylocked limiting users memorylocked The maximum amount of memory a process may request to be locked into main memory using &man.mlock.2;. Some system-critical programs, such as &man.amd.8;, lock into main memory so that if the system begins to swap, they do not contribute to disk thrashing. memoryuse memoryuse limiting users memoryuse The maximum amount of memory a process may consume at any given time. It includes both core memory and swap usage. This is not a catch-all limit for restricting memory consumption, but is a good start. openfiles openfiles limiting users openfiles The maximum number of files a process may have open. In &os;, files are used to represent sockets and IPC channels, so be careful not to set this too low. The system-wide limit for this is defined by the kern.maxfiles &man.sysctl.8;. sbsize sbsize limiting users sbsize The limit on the amount of network memory, and thus mbufs, a user may consume in order to limit network communications. stacksize stacksize limiting users stacksize The maximum size of a process stack. This alone is not sufficient to limit the amount of memory a program may use so it should be used in conjunction with other limits. There are a few other things to remember when setting resource limits. Following are some general tips, suggestions, and miscellaneous comments. Processes started at system startup by /etc/rc are assigned to the daemon login class. Although the /etc/login.conf that comes with the system is a good source of reasonable values for most limits, they may not be appropriate for every system. Setting a limit too high may open the system up to abuse, while setting it too low may put a strain on productivity. Users of &xorg; should probably be granted more resources than other users. &xorg; by itself takes a lot of resources, but it also encourages users to run more programs simultaneously. Many limits apply to individual processes, not the user as a whole. For example, setting openfiles to 50 means that each process the user runs may open up to 50 files. The total amount of files a user may open is the value of openfiles multiplied by the value of maxproc. This also applies to memory consumption. For further information on resource limits and login classes and capabilities in general, refer to &man.cap.mkdb.1;, &man.getrlimit.2;, and &man.login.conf.5;. Groups groups /etc/groups accounts groups A group is a list of users. A group is identified by its group name and GID. In &os;, the kernel uses the UID of a process, and the list of groups it belongs to, to determine what the process is allowed to do. Most of the time, the GID of a user or process usually means the first group in the list. The group name to GID mapping is listed in /etc/group. This is a plain text file with four colon-delimited fields. The first field is the group name, the second is the encrypted password, the third the GID, and the fourth the comma-delimited list of members. For a more complete description of the syntax, refer to &man.group.5;. The superuser can modify /etc/group using a text editor. Alternatively, &man.pw.8; can be used to add and edit groups. For example, to add a group called teamtwo and then confirm that it exists: Adding a Group Using &man.pw.8; &prompt.root; pw groupadd teamtwo &prompt.root; pw groupshow teamtwo teamtwo:*:1100: In this example, 1100 is the GID of teamtwo. Right now, teamtwo has no members. This command will add jru as a member of teamtwo. Adding User Accounts to a New Group Using &man.pw.8; &prompt.root; pw groupmod teamtwo -M jru &prompt.root; pw groupshow teamtwo teamtwo:*:1100:jru The argument to is a comma-delimited list of users to be added to a new (empty) group or to replace the members of an existing group. To the user, this group membership is different from (and in addition to) the user's primary group listed in the password file. This means that the user will not show up as a member when using with &man.pw.8;, but will show up when the information is queried via &man.id.1; or a similar tool. When &man.pw.8; is used to add a user to a group, it only manipulates /etc/group and does not attempt to read additional data from /etc/passwd. Adding a New Member to a Group Using &man.pw.8; &prompt.root; pw groupmod teamtwo -m db &prompt.root; pw groupshow teamtwo teamtwo:*:1100:jru,db In this example, the argument to is a comma-delimited list of users who are to be added to the group. Unlike the previous example, these users are appended to the group list and do not replace the list of existing users in the group. Using &man.id.1; to Determine Group Membership &prompt.user; id jru uid=1001(jru) gid=1001(jru) groups=1001(jru), 1100(teamtwo) In this example, jru is a member of the groups jru and teamtwo. For more information about this command and the format of /etc/group, refer to &man.pw.8; and &man.group.5;. + + + Becoming Superuser + + There are several ways to do things as the superuser. The + worst way is to log in as root directly. + Usually very little activity requires root + so logging off and logging in as root, + performing tasks, then logging off and on again as a normal user + is a waste of time. + + A better way is to use &man.su.1; without providing a login + but using - to inherit the root environment. + Not providing a login will imply super user. For this to work + the login that must be in the wheel group. + An example of a typical software installation would involve the + administrator unpacking the software as a normal user and then + elevating their privileges for the build and installation of + the software. + + + Install a Program As The Superuser + + &prompt.user; configure +&prompt.user; make +&prompt.user; su - +Password: +&prompt.root; make install +&prompt.root; exit +&prompt.user; + + + Note in this example the transition to + root is less painful than logging off + and back on twice. + + Using &man.su.1; works well for single systems or small + networks with just one system administrator. For more complex + environments (or even for these simple environments) + sudo should be used. It is provided as a port, + security/sudo. It allows for + things like activity logging, granting users the ability to only + run certain commands as the superuser, and several other + options. +