非常着急！！！！！！！！！！！！！！！！！！！！！！！！

yaoxiujun

hp unix上如何搭建时间同步服务器呀？？
怎么找不到 任何的ntpd的信息呀？？
希望知道的人抓紧给回个信息了，这里急用，先谢谢了！！！

oldnetangel

Configuration Overview

When xntpd starts, it reads a configuration file to find out its operating characteristics. The configuration file is called /etc/ntp.conf. This file is owned by root and is writeable only by root (it is readable by anyone). Modifying the configuration file is usually the responsibility of the system administrator.

To configure xntpd:

   1.

      Edit the xntpd configuration file /etc/ntp.conf. You can also use SAM to configure xntpd.

      Determine how you want to configure xntpd by reading the rest of this chapter and the xntpd man page. Then add the appropriate statements in /etc/ntp.conf.
   2.

      Set the environment variable XNTPD to 1 in the file /etc/rc.config.d/netdaemons. This causes xntpd to start automatically whenever the system is booted.
   3.

      Set the appropriate value for your local time zone in the file /etc/TIMEZONE.
   4.

      Run the xntpd startup script with the following command:

/sbin/init.d/xntpd start

   5.

      Run the ntpq program with the -p switch to verify that xntpd is forming the correct relationships with other NTP hosts. (See  "Querying xntpd" .)


Guidelines for Configuration

The following are guidelines that you should consider when planning your configuration:

    *

      Every NTP hierarchy must have at least one stratum-1 server. You may configure your administrative domain to have outside sources of synchronization which ultimately link to stratum-1 server(s), or you may implement your own hierarchy of NTP time servers with one or more stratum-1 servers. For example, an NFS-Diskless cluster may be configured as its own NTP hierarchy. In this topology, the NFS-Diskless server is configured as a stratum-1 NTP server, and may use its own system clock as the time server.
    *

      Configure at least three time servers in your administrative domain. It is important to provide multiple, redundant sources of synchronization, as NTP is specifically designed to select an optimal source of synchronization from several potential candidates. Each time server should be a peer with each of the other time servers. In Figure 7-8, “Example Configuration for an Administrative Domain”, each of these servers are depicted as a "Stratum 2 Server" within the administrative domain.
    *

      For each time server, select 1-3 outside sources of synchronization. This assures a relative degree of reliability in obtaining time, especially if you can select sources that do not share common paths. The sources should operate at a stratum level that is one less than the local time servers. In Figure 7-8, “Example Configuration for an Administrative Domain”, there are two stratum-1 sources shown for each server in the administrative domain.
             
             

      Note: An enterprise may implement its own hierarchy of NTP time servers, including stratum-1 servers. If your administrative domain is part of an enterprise-wide internet, you should check for available NTP resources in your enterprise. If your administrative domain does not have access to lower-stratum time servers, there are NTP servers on the Internet that are willing to provide public time synchronization. (Many stratum-1 and stratum-2 servers can be used only by permission of the administrator of the system; you should always check with the administrator before using an NTP server on the Internet.) The list of servers is available by anonymous ftp in the file pub/ntp/doc/clock.txt on Internet host louie.udel.edu (Internet address 128.175.1.3).
             
    *

      The outside sources of synchronization should each be in different administrative domains, and should be accessed from different gateways and access paths. Avoid loops and common points of failure. Do not synchronize multiple time servers in an administrative domain to the same outside source, if possible. See Figure 7-8, “Example Configuration for an Administrative Domain”.

      Figure 7-8. Example Configuration for an Administrative Domain
      Example Configuration for an Administrative Domain
    *

      For enterprise networks that contain hundreds or thousands of file servers and workstations, the local time servers should obtain service from stratum-1 servers. See the previously-mentioned clock.txt file for stratum-1 sources if your enterprise does not have its own NTP time server hierarchy.
    *

      Single, isolated workstations should not obtain time from a stratum-1 server. Workstations located in sparsely-populated domains without a local synchronization structure should request synchronization from servers that are stratum-2 or higher.
    *

      When defining a relationship between a server of a higher-numbered stratum and a server of a lower-numbered stratum, configure the relationship in the server of the higher-numbered stratum. For example, if a stratum-3 server is a client of a stratum-2 server, configure the relationship in the stratum-3 server. This simplifies configuration maintenance, since there is likely to be more configuration change in systems of higher-numbered stratums, such as workstations.
    *

      Use NTP broadcasting where possible and practical in order to reduce NTP traffic on subnets.


Configuration File

This section describes the statements that can be defined in the /etc/ntp.conf configuration file. Configuration file statements are described in the following subsections:

    *

       "Configuring Relationships with Other Time Servers"
    *

       "Configuring External Clocks"
    *

       "Configuring a Driftfile"
    *

       "Configuring Authentication"
    *

       "Restricting Incoming NTP Packets"


Configuring Relationships with Other Time Servers

The roles of a time server are its relationships to other servers in the synchronization subnet. In the configuration file, a role is defined with one of four statements (peer, server, broadcast, and broadcastclient):

peer host|IP_address specifies that the named host is to provide time that the local host may synchronize to, and the local host is willing to provide time to which the named host may be synchronized.

server host|IP_address specifies that the named host is to provide time that the local host might synchronize to, but the local host does not provide time to which the named host may be synchronized. (The local host is a client of the named host.) In addition, server statements are used to configure external clocks (radio clocks or local system clocks) for stratum-1 servers. Refer to  "Configuring External Clocks"  for more information.

broadcast host|broadcast_address specifies that the xntpd daemon in the local host transmits broadcast NTP messages to a named address, usually the broadcast address on your local network. (The local host is a broadcaster.)

With the peer, server, or broadcast statement, you can also specify one or more of the following options:

key number specifies that the NTP packets sent to the named host are encrypted using the key that is associated with number. The authentication feature of xntpd must be enabled. See  "Configuring Authentication" .

version 1 must be specified if xntpd will be requesting time from a host that is running ntpd, a daemon that is based on version 1 of the NTP protocol. version 2 must be specified if xntpd will be requesting time from a host that is running an xntpd implementation that is based on version 2 of the NTP protocol. If either of these options is not specified, xntpd sends out version 3 NTP packets when polling the host; if the host is a version 1 or 2 implementation, the packets will be discarded.

prefer specifies that the named host should be the primary source for synchronization when it is one of several valid sources. This option is most useful for a time server on a high-speed LAN that is equipped with an external time source, such as a radio clock. As mentioned in  "Guidelines for Configuration" , synchronization may be provided by outside sources. However, the local time server should be the preferred synchronization source.

The other role that you can define in the configuration file is that of a broadcast client. The statement broadcastclient yes indicates that the local host should listen for and attempt to synchronize to broadcast NTP packets. The optional statement broadcastdelay seconds specifies the default round trip delay to the broadcaster.
       
       

Note: Every node in an NTP hierarchy must have either a server statement or a broadcastclient yes statement in its configuration file. Every node must have an upper-level server. A stratum-1 server must also have a server statement in its configuration file, which specifies a radio clock or internal system clock as a time source.
       

Note that if the local host is to assume the role of a server in providing time to clients, there is no configuration of this role on the local system. Instead, the configuration file on the client system would contain a server statement with the name or IP address of the host.

Also note that if authentication is enabled on the local host, the roles you configure are subject to the authentication process. For example, the local host can be configured as a peer or a client of a stratum-1 server, but if the remote server does not meet the criteria for an authenticated synchronization source, it will never be used as a time source by the local host. See  "Configuring Authentication" .
       
       

Note: xntpd is an HP implementation of version 3.2 of a publicly-available NTP daemon. HP does not guarantee that xntpd is fully compatible with version 1 or version 2 implementations of the daemon.
       

Configuring External Clocks

You can configure xntpd to support an external clock. Clocks are normally configured with server statements in the configuration file. Clock addresses can be used anywhere else in the configuration file that a normal IP address is used—for example, in restrict statements.

Clocks are referenced by an address of the format 127.127.t.u, where t specifies the clock type, and u is a unit number, which is dependent on the clock type for interpretation (this allows multiple instances of the same clock type on the same host).

xntpd supports two kinds of clocks:

    *

      Netclock/2 WWVB Synchronized Clock. A system with this type of clock attached and configured is, by definition, a stratum-1 time server. The address used to configure the clock is 127.127.4.u, where u is a value between 1 and 4. You must create a device file /dev/wwvb%u.
    *

      Local synchronization clock, also known as a "pseudo" clock. A system with this type of clock configured uses the local system clock as a time source. The address used to configure this clock is 127.127.1.u, where u is a value between 0 and 15 and specifies the stratum level at which the clock runs. The local host, when synchronized to the clock, operates at one higher stratum level than the clock. This type of clock can be used in an isolated synchronization subnet where there is no access to a stratum-1 time server.

See the xntpd man page for more information on configuring external clocks.

Figure 7-7, “Example of Relationships Between Time Servers”, shown earlier in this chapter, depicts an example of servers in a synchronization subnet and their relationships to each other. Figure 7-9, “Example Configurations” shows the peer, server, and broadcast statements that are configured for each of the servers. The system that will assume the server role is configured on its client systems. For example, if Penelope is to be a client of Bonita, you configure the name or address of Bonita on Penelope. You do not need to configure Penelope as a client on Bonita.

Figure 7-9. Example Configurations
Example Configurations

Configuring a Driftfile

xntpd computes the error in the frequency of the clock in the local host. It usually takes xntpd a day or so after it is started to compute a good estimate of the frequency error. The current value of the frequency error may be stored in a driftfile. The driftfile allows a restarted xntpd to reinitialize itself to the estimate stored in the driftfile, saving about a day's worth of time in recomputing a good frequency estimate. You specify the path and name of the driftfile.
       
       

Note: xntpd should be operated on a continuous basis. If it is necessary to stop xntpd, the interval when it is not running should be kept to a minimum.
       

To specify the driftfile, define the keyword driftfile, followed by the name of the file in which the frequency error value is to be stored. The recommended location for the driftfile is /etc/ntp.drift. The following is an example of a driftfile statement:

driftfile /etc/ntp.drift


Configuring Authentication

Authentication is a mechanism that helps protect against unauthorized access to time servers. Authentication is enabled on a system-by-system basis. Once enabled on a system, authentication applies to all NTP relationships configured on the system. When authentication is enabled on a host, only those time servers that send messages encrypted with a configured key are considered as candidates to which the host would be synchronized.

In authenticated mode, each NTP packet transmitted by a host has appended to it a key number and an encrypted checksum of the packet contents. The key number is specified in the peer, server, or broadcast statement for the remote host. You specify either the Data Encryption Standard (DES) or the Message Digest (MD5) algorithm to be used for the encryption of NTP packets.

Upon receipt of an encrypted NTP packet, the receiving host recomputes the checksum and compares it with the one included in the packet. Both the sending and receiving systems must use the same encryption key, defined by the key number.

When authentication is enabled on a host, the following time servers will not be considered by the host for synchronization:

    *

      Time servers that send unauthenticated NTP packets.
    *

      Time servers that send authenticated packets that the host is unable to decrypt.
    *

      Time servers that send authenticated packets encrypted using a non-trusted key.

An authentication key file is specified on the host. The key file contains a list of keys and their corresponding key numbers. Each key-key number combination is further defined by a key format, which determines the encryption method being used. See the xntpd man page for more information about the content of the authentication key file. A sample key file is provided in /usr/newconfig/etc/ntp.keys. The recommended location for the key file is /etc/ntp.keys. The key file should be secured to allow only the system administrator to have read and write access (mode 600).

While the key file can contain many keys, you can declare a subset of these keys as trusted keys. Trusted keys are used to determine if a time server is "trusted" as a potential synchronization candidate. Only time servers that use a specified trusted key for encryption, and whose authenticity is verified by successful decryption, are considered synchronization candidates.

Figure 7-10, “Authentication Example” illustrates how authentication works.

Figure 7-10. Authentication Example
Authentication Example

In the example in Figure 7-10, “Authentication Example”, authentication is enabled for both Penelope and Golden. An NTP time request from Penelope to Golden will include authentication fields—the key ID 10, and a checksum encrypted with the key corresponding to the key ID 10, "tickle." When Golden receives this request, it recomputes the checksum using the packet's key ID field (10) to look up the key for ID 10 in its key file ("tickle" and compares it to the authentication field in the request.

Golden will send back time information with the key ID 10 and a checksum encrypted using "tickle."

In addition, Penelope will only accept time synchronizations that have used the key ID 10 and the corresponding encryption key "tickle."

To enable authentication on the local host, include the following statement in the /etc/ntp.conf configuration file:

authenticate yes

If the above statement is not specified, no authentication is used. When authentication is enabled, the following keywords and parameters may also be specified:

authdelay seconds indicates the amount of time (in seconds) needed to encrypt an NTP authentication field on the local host. The seconds value is used to correct transmit timestamps for authenticated outgoing packets. The value depends upon the CPU speed of the local host.
       
       

Caution: The startup script automatically calculates the proper value for authdelay for the local system and writes it into the configuration file /etc/ntp.conf. Do not modify this value.
       

keys filename specifies the file that contains the encryption keys used by xntpd. See the xntpd man page for the format of the file.

trustedkey key# [key#2]... specifies the encryption key ID(s) that are trusted as synchronization sources.

Restricting Incoming NTP Packets

xntpd provides a mechanism for restricting access to the local daemon from certain source addresses. In the /etc/ntp.conf file, you can define a restriction list that contains the addresses or addresses-and-masks of sources that may send NTP packets to the local host. For each address or address-mask specified in the restriction list, you can define zero or more flags to restrict time service or queries to the local host.

The source address of each incoming NTP packet is then compared to the restriction list. If a source address matches an entry in the restriction list, the restriction defined by the corresponding flag is applied to the incoming packet. If an address-mask is specified in the restriction list, the source address of each incoming NTP packet is ANDed with the mask, and then compared with the associated address for a match.

The restriction list should not be considered an alternative to authentication. It is most useful for keeping unwanted or broken remote time servers from affecting your local host. An entry in the restriction list has the following format:

restrict address [mask mask] [ntpport] [flag] [flag2]...

The keyword ntpport causes the restriction list entry to be matched only if the source port in the packet is the NTP UDP port 123.

Table 7-1, “Restrict Option Flags” shows the flags that can be specified for xntpd:

Table 7-1. Restrict Option Flags

Flag
       

Effect

ignore
       

Ignore all packets.

noquery
       

Ignore ntpq queries.

nomodify
       

Ignore ntpq packets that attempt to modify the state of the server.

noserve
       

Ignore requests for time, but permit ntpq queries.

nopeer
       

Provide time service, but do not form peer association.

notrust
       

Do not use the host as a synchronization source.


A restriction list entry with no flags set leaves matching hosts unrestricted. A source address of an incoming packet may match several entries in the restriction list. The entry that matches the source address most specifically is the entry that is applied. For example, consider the following restriction list entries:

restrict 193.100.0.0 mask 255.255.0.0 ignore
restrict 193.100.10.8

The first entry causes packets from source addresses on net 193.100 to be ignored. However, packets from host 193.100.10.8 are unrestricted, as specified by the second entry. The two restriction list entries effectively cause all packets from net 193.100 to be ignored, with the exception of packets from host 193.100.10.8.

The following are examples of restriction list entries for a local host with the address 193.100.100.7. These entries assume that ntpq requests to the local host can be made only from the local host or the host with address 193.8.10.1, while the local host only synchronizes to a time source on net 193.100.

#default entry - matches *all* source addresses
restrict default notrust nomodify

#trust for time, but do not allow ntpq requests
restrict 193.100.0.0 mask 255.255.0.0 nomodify noquery

#ignore time requests, but allow ntpq requests
restrict 193.8.10.1 noserve

#local host address is unrestricted
restrict 193.100.100.7

李放

我们在配置CLUSTER时，一般都需要所有的主机都拥有一个相同的系统时间，及时间同步。这就需要用到XNTPD：
在启动XNTPD之前，我们需要选定一台或多台机器做为NPT的SERVER端，其它的机器则为CLIENT。配置方法很简单：
1. Server端:
编辑/etc/ntp.conf文件,在其文件结尾添加以下两行:

server 127.127.1.1
fudge 127.127.1.1 stratum 10
编辑完成后重启xntpd:
#/sbin/init.d/xntpd stop
#/sbin/init.d/xntpd start

2. Client端:
编辑/etc/rc.config.d/netdaemons文件:
将export NTPDATE_SERVER=改为export NTPDATE_SERVER=服务器IP地址
将XNTPD＝改为export XNTPD=1

等待服务器端xntpd进程运行5分钟后,在客户端启动xntpd进程:
#/sbin/init.d/xntpd stop
#/sbin/init.d/xntpd start

yaoxiujun

谢谢大家了，我正再配置呢，祝大家天天开心!!