You could put the name of the z/OS system (the one associated with your VIPA there) into your linux /etc/hosts during the test.
Marcy Cortes "This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation." -----Original Message----- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of James Melin Sent: Tuesday, April 24, 2007 11:32 AM To: [email protected] Subject: [LINUX-390] DNS and Disaster Recovery Good afternoon, fellow list dwellers.... I've a question/philosophical problem to pose. To frame this, in normal production I point my virtual servers at a primary and secondary DNS server that run in our network on a non-z platform. I don' tknow what platform and for the scope of this, it's irrelevant. I also used to point to the DNS on z/OS (using the non-vipa address) as a tertiary DNS source. I was asked to change this because the z/OS TCP/IP person was seeing errors logged for DNS requests to the z/OS machine from the Linux machines when DNS wasn't up (Even though the DNS was the third position) On z/OS we have a DNS server running that basically gets the DNS information available from the other DNS servers but is not a primary node of any kind and we don't use it to answer DNS requests except at Disaster Recovery, when no other DNS service is available (Because our distributed folks are still not doing a real DR model, they do second site failover as a strategy). The problem is compounded by the fact that my virtual servers use RACFLDAP on z/OS as the authentication mechanisim, and at DR, only the 'local/real/' address of the z/OS recovery system is available (It is the same as the production z/OS image at home) but the VIPA expopsed address is not used/not enabled so that we can have a single flat network all in the same subnet. The LDAP confg has a DNS-resolved name as the target LDAP server which is then used by the PAM modules to authenticate. Because I was asked to remove the address for the z/OS DNS server from the Linux configuration, we of course had difficulty getting LDAP calls to go through because the DNS resolved address was unavailable. This caused LDAP requests to time out. I was wondering what people have done in a situation like this, and if anyone could tell me what configuration file to change during startup of Linux (before tcp/ip starts) to define the DR DNS address, or if there was a better solution to this proposal. I can very easily enable the detection of whether or not a disaster recovery/test recovery in process, but I'm not sure what all needs to change to supply the correct IP address for DNS services in this case. Any thoughts/comments appreciated. -J ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
