SUMMARY (PARTIAL) sharing disks and DNS forwarding (Solaris)

From: Lucio Chiappetti (
Date: Wed Mar 25 1998 - 05:45:45 CST

On Tue, 24 Mar 1998, Lucio Chiappetti wrote:

> Our wish would be to use NIS for standard maps (passwd, aliases, services,
> etc.) *BUT* for hosts, and use DNS *exclusively* for propagating hosts
> information.

I have received some replies to my query of yesterday, but I have the
impression I've been not clear enough about our needs. I summarize the replies
below, and narrow my question.

  - we want to be able to "export" disks of several of our machines to
    some of the other. To do this we use in dfstab commands like :

    share -F nfs -o rw=helios::ares:rea:atlas:leda: /ogigia
  - all machines are NIS clients and DNS clients of the same server.
    All clients have a proper resolv.conf, as it has the server.

    (what should the Solaris NIS clients have in nsswitch.conf ? see

  - The server runs Solaris 2.5.1, the NISkit (i.e. NIS *NOT NISplus*),
     has in the /var/yp Makefile the B= flag set to null, and
> We have disabled in /etc/init.d/yp DNS forwarding, using $YPDIR/ypserv and
> not $YPDIR/ypserv -d.

  - we wish to mantain on the server a SINGLE file with host names, i.e.
     the SOA file of the DNS.

At the moment we are unable to do that. To have things working we are forced
to have on the server two files :

      - the DNS SOA file, listing all hosts in our domain
      - the NIS map (based on /etc/inet/hosts), listing all UNIX machines
        in our domain. We would like to get rid of this file and have it
        contain only the host itself as on any other machine

      - on clients the nsswitch.conf is set to

        hosts: nis dns [NOTFOUND=return] files
The "dns" entry is essential for the clients to communicate with the world.
We are ready to change the hosts line in any form (we thought that "files dns"
was a good choice, for analogy with our Alphas, and also Casper Dik agrees on

The replies we have received seems to concentrate on the fact that :

     - Thomas Anders, Joel Lee, David Thorburn-Gundlach and
       Gustavo Chaves all indicate that if one uses unqualified names
       in the share command the query is resolved via NIS, if one uses
       fully qualified names it is resolved via DNS

     - on the other hand it is prohibitively long to list 15-20 machines
       in full qualified form in the dfstab file

     - Thomas Anders, Joel Lee, David Thorburn-Gundlach suggest the use
       of netgroups, but then we'll have yet another file to mantain (we
       already do it for hosts.equiv), and moreover the entries in
       netgroup are of the form

       kalypso (kalypso,,

       which implies the name is resolved via NIS, so it won't help us.

I also received a reply by David Thorburn-Gundlach saying

>It so happens, however, that you *will* be able to resolve through
>NIS, even with the -B flag set to jull, if you have a /etc/resolv.conf
>file on your YP master; /etc/init.d/yp tests (on my line 87) for
>/etc/resolv.conf and fires off rpc.nisd_resolv (instead of rpc.nisd)
>if it is found.
I looked in the man pages of netconfig. rcp.nisd and rpc.nisd_resolv, but I
note that no such daemon is running on our systems, the first of such files is
referred in /etc/init.d/rcp, not in /etc/init.d/yp (which on our systems is
present on the NIS server only, and comes from the NISkit).

I notice that apparently "share" behaves differently from other commands
(ping, telnet, ftp) for what concern name resolution. If I do ping or telnet
an unqualified name, corresponding to a non-Unix machine (PC, VMS, NT) in our
domain, the query is answered by DNS.

Why share is different ?
Is it really so (a "feature") or can we turn it to work as the others and get
rid of a NIS mantained host map ?

Lucio Chiappetti - IFCTR/CNR - via Bassini 15 - I-20133 Milano (Italy)
Fuscim donca de Miragn E tornem a sta scio' in Bregn
Che i fachign e i cortesagn Magl' insema no stagn begn
Drizza la', compa' Tapogn (Rabisch, II 41, 96-99)
For more info :

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:12:34 CDT