RE: [9fans] dhcp & metanames

RE: [9fans] dhcp & metanames

[Tiit Lankots]

> 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.

OK, I'll rephrase. How long will it take for timesync to annihilate a 2-hour
difference?

RE: [9fans] dhcp & metanames

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 277 bytes --]

immediate.  It the diff is > 10 seconds it just sets it.

you have some other problem.  everyone that dual boots with
windows that doesn't live on the prime meridian (myself
included) is in the same boat.

cd /adm/timezone
cp EET local

reboot and see how things look.

[-- Attachment #2: Type: message/rfc822, Size: 2369 bytes --]

From: "Tiit Lankots" <t.lankots@aprote.ee>
To: <9fans@cse.psu.edu>
Subject: RE: [9fans] dhcp & metanames
Date: Sun, 7 Mar 2004 15:58:18 +0200
Message-ID: <81132473206F3A46A72BD6116E1A06AE479D33@black.aprote.com>

> 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.

OK, I'll rephrase. How long will it take for timesync to annihilate a 2-hour
difference?

Re: [9fans] dhcp & metanames

[Derek Fawcus]

On Sun, Mar 07, 2004 at 10:55:41AM -0500, David Presotto wrote:
> 
> everyone that dual boots with windows that doesn't live on the
> prime meridian is in the same boat.

and even when one does live on prime meridian (or as near as damn it),
windows still get's confused for half the year...

RE: [9fans] dhcp & metanames

[Tiit Lankots]

OK, I finally got it. The timezone name needs to be 3 letters _exactly_ 
or it will get confused.

Tiit@enlightened

RE: [9fans] dhcp & metanames

[Tiit Lankots]

> It will work.

I have /adm/timezone/local set up (and it ends in a line feed).
It doesn't work.

RE: [9fans] dhcp & metanames

[David Tolpin]

> > It will work.
>
> I have /adm/timezone/local set up (and it ends in a line feed).
> It doesn't work.
>

What's in the file?

cpu%timezone='EET 7200 EDT 10800

'
cpu%date
Sun Mar  7 17:28:12 EET 2004
cpu% timezone='AMT 14400 AMD 18000

'
cpu% date
Sun Mar  7 19:32:14 AMT 2004
cpu% 

RE: [9fans] dhcp & metanames

[Tiit Lankots]

Still, why are date(1) and friends telling the time in GMT
when  $timezone is set differently?

RE: [9fans] dhcp & metanames

[David Tolpin]

>
> Still, why are date(1) and friends telling the time in GMT
> when  $timezone is set differently?
>

timezone is meant to be set from /adm/timezone/local; the parser
requires a linefeed at the end. Set it to

timezone='EET 7200 EDT 10800
'

It will work.

RE: [9fans] dhcp & metanames

[Tiit Lankots]

>   be of the form dom=.machine.com (NB: leading dot).
> 
> If it is wrong, I'll change it to the fqdn.

i've always used the fqdn and works like a charm.
my dhcp server doesn't return names, tho

RE: [9fans] dhcp & metanames

[Tiit Lankots]

>       dom=.home.davidashen.net

it's probably confused by the leading dot

RE: [9fans] dhcp & metanames

[Tiit Lankots]

> /net/ndb is used by cs and dns before /lib/ndb.  If you have 
> an entry for
> the network in /lib/ndb/local with the smtp=, 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.

RE: [9fans] dhcp & metanames

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 771 bytes --]

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.

[-- Attachment #2: Type: message/rfc822, Size: 2942 bytes --]

From: "Tiit Lankots" <t.lankots@aprote.ee>
To: <9fans@cse.psu.edu>
Subject: RE: [9fans] dhcp & metanames
Date: Sun, 7 Mar 2004 15:15:37 +0200
Message-ID: <81132473206F3A46A72BD6116E1A06AE056167@black.aprote.com>

> /net/ndb is used by cs and dns before /lib/ndb.  If you have 
> an entry for
> the network in /lib/ndb/local with the smtp=, 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.

RE: [9fans] dhcp & metanames

[David Tolpin]

> > /net/ndb is used by cs and dns before /lib/ndb.  If you have 
> > an entry for
> > the network in /lib/ndb/local with the smtp=, 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 think it's about mailserver in /cron/mail/cron. Edit it and replace
with your mailserver's name  or add mailserver to the dns.  sys=mailserver, 
that is.

[9fans] dhcp & metanames

[Tiit Lankots]

I'm getting my IP setup from a (non-Plan 9) DHCP server.
It doesn't contain the name of the mail server.
Hence, /net/ndb doesn't contain it.
Hence, mail isn't working.
Setting smtp=... in /lib/ndb/local has no effect.

Suggestions?
Also, how does /net/ndb relate to /lib/ndb?

Tiit

Re: [9fans] dhcp & metanames

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 256 bytes --]

/net/ndb is used by cs and dns before /lib/ndb.  If you have an entry for
the network in /lib/ndb/local with the smtp=, it will be found.

Alternatively, you can do this in termrc or cpurc:

	echo '	smtp=....' >> /net/ndb

after you do the ipconfig.

[-- Attachment #2: Type: message/rfc822, Size: 2347 bytes --]

From: "Tiit Lankots" <t.lankots@aprote.ee>
To: "Plan 9 Mailing List (E-mail)" <9fans@cse.psu.edu>
Subject: [9fans] dhcp & metanames
Date: Sun, 7 Mar 2004 12:08:59 +0200
Message-ID: <81132473206F3A46A72BD6116E1A06AE056166@black.aprote.com>

I'm getting my IP setup from a (non-Plan 9) DHCP server.
It doesn't contain the name of the mail server.
Hence, /net/ndb doesn't contain it.
Hence, mail isn't working.
Setting smtp=... in /lib/ndb/local has no effect.

Suggestions?
Also, how does /net/ndb relate to /lib/ndb?

Tiit

Re: [9fans] dhcp & metanames

[David Tolpin]

/net/ndb:
ip=192.168.1.28 ipmask=255.255.255.0 ipgw=192.168.1.1
      dom=.davidashen.net
      dns=192.168.1.1

/lib/ndb/local:
sys=xotic ether=0002a5561d54 proto=il 
      ip=192.168.1.28 ipmask=255.255.255.0
      dom=.home.davidashen.net

Shouldn't dom in /net/ndb be .home.davidashen.net?

David

Re: [9fans] dhcp & metanames

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 766 bytes --]

First of all, dom in our world is an FQDN. That means that both
.home.davidashen.net and .davidachen.net are wrong.

We ask dhcp for a hostname and a domain.  For the latter, dhcp's
seem to differ in what they give back, i.e., the FQDN of the machine,
the FQDN domain name that the machine is in, or that FQDN starting
with a '.'.    Ipconfig tries to deal with the situation, clearly
not well enough.  I'll try to do better but, if the server doesn't
return the hostname, its hard to guess.  the dom=.davidashen.net 
clearly indicates that we only got the domain and not the hostname.
This is a effect of the spread of windows where the hostname is
always in local storage and diskless boot is not really considered.

I'll try to do better in ipconfig.

[-- Attachment #2: Type: message/rfc822, Size: 2393 bytes --]

From: David Tolpin <dvd@davidashen.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] dhcp & metanames
Date: Sun, 7 Mar 2004 17:13:53 +0400 (AMT)
Message-ID: <200403071313.i27DDrDh079473@adat.davidashen.net>

/net/ndb:
ip=192.168.1.28 ipmask=255.255.255.0 ipgw=192.168.1.1
      dom=.davidashen.net
      dns=192.168.1.1

/lib/ndb/local:
sys=xotic ether=0002a5561d54 proto=il 
      ip=192.168.1.28 ipmask=255.255.255.0
      dom=.home.davidashen.net

Shouldn't dom in /net/ndb be .home.davidashen.net?

David

Re: [9fans] dhcp & metanames

[David Tolpin]

> We ask dhcp for a hostname and a domain.  For the latter, dhcp's
> seem to differ in what they give back, i.e., the FQDN of the machine,
> the FQDN domain name that the machine is in, or that FQDN starting
> with a '.'.    Ipconfig tries to deal with the situation, clearly
> not well enough.  I'll try to do better but, if the server doesn't
> return the hostname, its hard to guess.  the dom=.davidashen.net 
> clearly indicates that we only got the domain and not the hostname.
> This is a effect of the spread of windows where the hostname is
> always in local storage and diskless boot is not really considered.

I have no Windows server in my network; the dhcp server sends domain
names.

I have only done that (the leading dot) because

http://www.cs.bell-labs.com/wiki/plan9/Mail_configuration/

in the last paragraph says:

  This name is generated from either the site enviroment var, or if that is not
  set, by appending the sending machines domain to its system name. The domain is
  picked up from the dom= attribute from /lib/ndb/local. The dom= attribut should
  be of the form dom=.machine.com (NB: leading dot).

If it is wrong, I'll change it to the fqdn.

Re: [9fans] dhcp & metanames

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 115 bytes --]

It's wrong.  Unfortunately, I don't vet the wiki.  People put in whatever
accidentally worked.  I'll go change it.

[-- Attachment #2: Type: message/rfc822, Size: 3287 bytes --]

From: David Tolpin <dvd@davidashen.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] dhcp & metanames
Date: Sun, 7 Mar 2004 17:49:35 +0400 (AMT)
Message-ID: <200403071349.i27DnZru079594@adat.davidashen.net>

> We ask dhcp for a hostname and a domain.  For the latter, dhcp's
> seem to differ in what they give back, i.e., the FQDN of the machine,
> the FQDN domain name that the machine is in, or that FQDN starting
> with a '.'.    Ipconfig tries to deal with the situation, clearly
> not well enough.  I'll try to do better but, if the server doesn't
> return the hostname, its hard to guess.  the dom=.davidashen.net 
> clearly indicates that we only got the domain and not the hostname.
> This is a effect of the spread of windows where the hostname is
> always in local storage and diskless boot is not really considered.

I have no Windows server in my network; the dhcp server sends domain
names.

I have only done that (the leading dot) because

http://www.cs.bell-labs.com/wiki/plan9/Mail_configuration/

in the last paragraph says:

  This name is generated from either the site enviroment var, or if that is not
  set, by appending the sending machines domain to its system name. The domain is
  picked up from the dom= attribute from /lib/ndb/local. The dom= attribut should
  be of the form dom=.machine.com (NB: leading dot).

If it is wrong, I'll change it to the fqdn.