Conference abbott::mailworks-vms

1536.0. "mail notif on DHCP clients" by GIDDAY::LEH () Thu Feb 06 1997 02:41

Rob in note 1489.9 explained:
    
> 	When the server delivers a mail message, it then checks to see if
> the particular user has an entry in the notification table.  If it finds
> an entry in the table, it then checks to see what type of transport the user
> used to connect with - if it is UDP then it attempts to load the TCP 
> information for the client node into the IOSB (which will then be used to 
> send the notification).  So, the server makes a $QIOW call to do the
> gethostbyname, and it first uses whatever is in the Nodepath field in the
> notification table.  If this fails to return and address, it then does
> another $QIOW call to do another gethostbyname, but this time it uses what
> is in the Nodename field in the notification table.  If this call also fails,
> it then outputs the error - "Error calling gethostbyname for node <%s>" and
> sticks in the Nodepath for <%s>.

Does this mean a *valid* Nodepath value would prevent the mail server from 
doing the second gethostbyname to examine Nodename field ?

I came across this problem

1997013117041431 000 %SSI_ERROR, SSI error; Name NOTIFY, code 290019, status 0,
 string-info Error calling gethostbyname for node, <172.20.100.27>, int-info 0
1997013117041440 000 %SSI_ERROR, SSI error; Name NOTIFY, code 290019, status 0,
 string-info Error calling gethostbyname for node, <172.20.100.27>, int-info 0

for this client

BOTWRIGHTJ.      .            YES      UDP            172.20.100.27.

It looked 2 $QIOW calls despite of the valid address 172.20.100.27

This PC as a result didn't receive any mail notification, and it was suspected 
changes of the name servers on the VAX host wasn't done via proper IP config 
routine; e.g.

$ ucx show name

BIND Resolver Parameters

 Local domain: hydro.com.au

 System

  State:     Started, Enabled

  Transport: UDP
  Domain:    hydro.com.au
  Retry:     4
  Timeout:   4
  Servers:   PNT119, MAILGATE

but

UCX> sh config name

BIND Resolver Configuration

  Transport:  UDP
  Domain:     hydro.com.au
  Retry:         4
  Timeout:       4
  Servers:    172.20.1.170, 172.20.1.121

where MAILGATE being 172.20.1.170 and PNT119 being 172.20.1.119

The affected PC entry existed in PNT119, but not in MAILGATE, nor in 
172.20.1.121

Does MailWorks rely on permanent databse, and not on volatile/cache ?

This site started using DHCP, so their WINS database has to be reconciled with 
DNS, which is also a potential source of conflicts/stale updates. 

I hope MailWorks shouldn't be affected by DHCP/WINS changes, e.g. client's IP 
address changes at end of lease period; so long as DNS name servers can 
gurantee the currency of address/nodename

Thanks for any comments

Hong

The same VAX host has been reconfigured with correct DNS name servers, and a 
node reboot followed. Most of the affected TL clients now received mail notif, 
but there're still a couple that weren't. 

I noticed the mail notif database was still having entries with no nodename, 
eg. BOTWRIGHTJ.      .            YES      UDP            172.20.100.27.

and yet this PC seemed to have received mail notif. Unfortunately, the ones 
that didn't receive mail notif also had null nodename in their records, and 
EVL error log reported gethostbyname errors on the latter.

My checking on name servers didn't reveal any anomalies.

So, must the nodename be present in the database record for mail notif to 
arrive at the PC ? where does MailWorks get address/nodename from ?

Hong