Starting the adnisd process

After you have specified the subnets from which to accept NIS client requests, you can either manually start the adnisd process at the command line, or reboot the local computer. By default, the adnisd process starts automatically whenever the computer is rebooted. If you don’t want the process started automatically, you should modify the startup script on the local computer to remove adnisd from the processes started.

Note:   The installer adds the adnisd process to a computer’s startup script for you. If you are not importing NIS maps right away, you may want to modify the startup script to prevent the adnisd process from starting before you are ready to begin servicing client requests.

To start the adnisd process at the command line:

  1. Verify that adclient is running and the local computer is joined to a domain.
  2. Verify that RPC is running on the local computer. For example:

    rpcinfo -p localhost

    The adnisd process requires RPC services. If you restart RPC, you also need to restart the adnisd process.

  3. Type the appropriate start command. For example, on Red Hat Linux, type:

    /sbin/service adnisd start

    On most other platforms, run:

    /etc/init.d/adnisd start

    On Solaris 10 or later, the daemon is controlled through the Solaris Service Management Facility. For example:

    svcadm enable nis/centrifydc-server

When the adnisd process starts, it connects to Active Directory through adclient and does the following:

  • Retrieves the current user, group, network and custom information stored in Active Directory for its zone.
  • Generates additional maps derived from the retrieved information, such as netgroup.byuser, netgroup.byhost, passwd.byuid, passwd.byname, group.byname, and group.bygid.
  • Stores the information retrieved or derived from Active Directory in a local cache of NIS map data.

After the initial connection, adnisd periodically connects to Active Directory through adclient to retrieve updated information for its zone. However, adnisd always responds to NIS client requests using the data in its local cache so that it can respond to NIS requests even if Active Directory is unavailable.