From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <684b651b33f17d72d25a4d82b12e622b@plan9.bell-labs.com> From: David Presotto To: 9fans@cse.psu.edu Subject: RE: [9fans] dhcp & metanames In-Reply-To: <81132473206F3A46A72BD6116E1A06AE056167@black.aprote.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-bsdoteznqwbabvvehdaqghnset" Date: Sun, 7 Mar 2004 08:35:32 -0500 Topicbox-Message-UUID: 1e2d8d9c-eacd-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-bsdoteznqwbabvvehdaqghnset Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit There's no reason for the RTC to be in local time. One way to compensate is to reset it to GMT. However, if you're sharing a clock with Windows, you're stuck with their idiocy (i.e. a clock that is always at the wrong time until the system resets it if you live in a world with daylight savings time). Timesync sets the os's view of time. With -r it sets time from the RTC rather than a network source and stays synced with it. With -rL it sets from the RTC and assumes the RTC is in local time. Timesync never sets the RTC. This means that the system, by reading the RTC on boot, will be in the wrong time zone till timesync gets in there. Boot can't do any better because the file system with the timezone files hasn't started yet at that point. --upas-bsdoteznqwbabvvehdaqghnset Content-Type: message/rfc822 Content-Disposition: inline Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Sun Mar 7 08:16:21 EST 2004 Received: from mail.cse.psu.edu ([130.203.4.6]) by plan9; Sun Mar 7 08:16:18 EST 2004 Received: by mail.cse.psu.edu (CSE Mail Server, from userid 60001) id E6C4A19C8B; Sun, 7 Mar 2004 08:16:15 -0500 (EST) Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.4.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 556AE19C6F; Sun, 7 Mar 2004 08:16:12 -0500 (EST) X-Original-To: 9fans@cse.psu.edu Delivered-To: 9fans@cse.psu.edu Received: by mail.cse.psu.edu (CSE Mail Server, from userid 60001) id C7B9319C7D; Sun, 7 Mar 2004 08:15:36 -0500 (EST) Received: from ns.aprote.ee (ns.aprote.ee [80.235.78.106]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 2DEAC19BF5 for <9fans@cse.psu.edu>; Sun, 7 Mar 2004 08:15:35 -0500 (EST) Received: Message by Barricade ns.aprote.ee with ESMTP id i27DNjac030240 for <9fans@cse.psu.edu>; Sun, 7 Mar 2004 15:23:45 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [9fans] dhcp & metanames X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <81132473206F3A46A72BD6116E1A06AE056167@black.aprote.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [9fans] dhcp & metanames Thread-Index: AcQERBPiKw4KRfmDQoqguL9J+u8BmwAAEfpw From: "Tiit Lankots" To: <9fans@cse.psu.edu> Sender: 9fans-admin@cse.psu.edu Errors-To: 9fans-admin@cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: 9fans@cse.psu.edu List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Archive: Date: Sun, 7 Mar 2004 15:15:37 +0200 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psuvax1.cse.psu.edu X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Level: > /net/ndb is used by cs and dns before /lib/ndb. If you have=20 > an entry for > the network in /lib/ndb/local with the smtp=3D, it will be found. It was _not_ found. That's the whole problem that made me wonder if /lib/ndb/local is consulted at all. Later I realised that the search is probably conducted by IP address, but there's no address given in /lib/ndb/local 'cos its pointless. I solved the problem by defining a network with the correct parameters. OT: How to compensate for the fact that the real-time clock is in local = time? date(1) and friends constantly show me the time in GMT, although I've = set /adm/timezone/local. Also, how does timesync(8) fit into the picture? I mean, if I've set it = up to synchronise with a NTP server, is the RTC updated into GMT? Presumably not if the -L flag is given? It's a multiboot machine and i'd like to keep the RTC local. --upas-bsdoteznqwbabvvehdaqghnset--