3    Managing the Name Space

The name space contains the names and network addresses of the objects (spoolers, supervisors, logical and physical printers, and queues) that you create. The name service entry for each object contains information that includes the address of the server that supports it.

Clients and servers use the name service to locate and bind to the server that supports a specified network object. When a client or server requires the binding of a printer name or a server name, it uses the name service to obtain this information. The name service looks up the requested name and returns the requested binding to the client. The remote procedure call (RPC) mechanism uses the returned binding to connect to the server.

Advanced Printing Software supports the following name services:

The client and the server processes use Local File Name Service and NIS services by default.

This chapter also explains how to modify the default behavior through the configuration file, apx.conf and the protoserver daemon.

3.1    Local File Name Service

The Local File Name Service works in a single, stand-alone system configuration or in a distributed environment:

In a stand-alone configuration, the client and servers (spooler and supervisor) reside on the same workstation. When you create printing objects, the name service makes their binding information immediately available; when you delete them, the name service immediately removes their binding information.

The Local File Name Service stores printer binding information in the /etc/printers.conf file. A separate instance of the file exists on each host system. The print system does not support multiple hosts sharing a single /etc/printers.conf file. The following is an example of a printers.conf file:

#
#	Local namespace datafile for Advanced Printing Software
#
bulldog_sup:\
:saddr=bulldog.gandalf.xyz.com,105004,1,sys,sv,bulldog_sup,1:
bulldog_spl:\
:saddr=bulldog.gandalf.xyz.com,105004,1,sys,sl,bulldog_spl,1:
bulldog1:\
:paddr=bulldog.gandalf.xyz.com,105004,1,sys,pp,bulldog_sup,1:
bulldog_q:\
:qaddr=bulldog.gandalf.xyz.com,105004,1,sys,qu,bulldog_spl,1:
bulldog_log:\
:paddr=bulldog.gandalf.xyz.com,105004,1,sys,lp,bulldog_spl,1:\
:spooling-type=dpa:
cc3:\
:paddr=bulldog.gandalf.xyz.com,105004,1,sys,pp,bulldog_sup,1:

The server startup process automatically generates the printers.conf file if the server attempts to add an entry to the local file and the file does not exist. Also, the servers compare the content of the object database to the local file and add objects to it if they are in the database but not in the local file.

Because the object creation operation updates the local file only on the host where you executed the operation, the information is not available to clients or servers on other hosts. Therefore, when using the Local File Name Service in a distributed environment, you should create the configuration file in advance and copy it to all hosts that run clients or servers.

You can create the printers.conf file with an editor, or you can create the file by creating all print objects from a single host. However, in the second case, because you do not create servers with the create operation, you must manually add the server entries to the file for each different host. You will have to update the file on all hosts if you delete an object.

For the Local File Name Service:

3.2    Network Information Service

Network Information Service (NIS) uses the same format for printer configuration entries that is used for the Local File Name Service. However, NIS provides a means for administering and distributing that same printer configuration data to an entire NIS domain.

The most important difference between using Local File Name Service and using NIS is that the print system cannot modify NIS entries. Instead, you must manually update an NIS entry in an NIS file. You must either have the authority to make changes to the NIS file or have a proxy administrator with the authority to make the changes.

NIS requires a coordinated update of configuration changes. That is, you must add an object name to the NIS file before you create the print system object. However, unlike the Local File Name Service where you have to update the local file in each of multiple hosts, you need to update data in only one place with NIS.

To distribute the names and locations of printers, servers, and queues to hosts that are set up as NIS clients, gather one or more printers.conf files from those hosts where the print system server processes run and merge them into a master map file in /var/yp/src/printers.conf. You can use a text editor to merge the contents of those files. If the resulting file contains duplicate entries, use the text editor to remove the duplicates.

To update the NIS map on the NIS server after you have created the master printers.conf file:

  1. Log in as root.

  2. If you have not done so already, copy /usr/pd/scripts/Makefile.printers to /var/yp/Makefile.printers.

    # cp /usr/pd/scripts/Makefile.printers /var/yp/Makefile.printers
    

    Edit the copy of the file to define your NIS domain with the DOM variable.

  3. Set the current directory to /var/yp/src.

    # cd /var/yp/src
    

  4. Copy all pertinent printers.conf files from various hosts to the current directory, giving each a unique name.

    # cp /etc/printers.conf ./ 
    

  5. Use a text editor to merge the contents of these files into a new master printers.conf file.

    # mv printers.conf printers.conf.<date>
    # cat printers.conf.host1 printers.conf.host2\
    printers.conf > printers.conf
    

  6. Change the current directory to /var/yp.

    # cd ..
    

  7. Run the Makefile.printers file with the printers.conf (or "all") target to remake and redistribute the printers map.

    # make -f Makefile.printers
    updated printers.conf
    pushed printers.conf
     
     
    

  8. Verify that the new printers.conf map is available.

    # ypcat printers.conf.byname
    

This command produces output similar to the following; one line of information for each server, printer, and queue listed in the master map:

WS_sharie_PP:paddr=wstent.gandalf.xyz.com,105004,1,sys,pp,wstent_sup,1:
ws_lg_queue:qaddr=wstent.gandalf.xyz.com,105004,1,sys,qu,wstent_spl,1:
WS_cross_PP:paddr=wstent.gandalf.xyz.com,105004,1,sys,pp,wstent_sup,1:
WS_cress_PP:paddr=wstent.gandalf.xyz.com,105004,1,sys,pp,wstent_sup,1:
wstent_sup:saddr=wstent.gandalf.xyz.com,105004,1,sys,sv,wstent_sup,1:
ws_lg04_pp:paddr=wstent.gandalf.xyz.com,105004,1,sys,pp,wstent_sup,1:
glypha_spl:saddr=glypha.gandalf.xyz.com,105004,1,sys,sl,glypha_spl,1:
glypha_obg:saddr=glypha.gandalf.xyz.com,105004,1,sys,sv,glypha_obg,1:
WSQ1:qaddr=wstent.gandalf.xyz.com,105004,1,sys,qu,wstent_spl,1:
BigLinePrinter:paddr=wstent.gandalf.xyz.com,105004,1,sys,lp,wstent_spl,1:\ 
:spooling-type=dpa:
wstent_spl:saddr=wstent.gandalf.xyz.com,105004,1,sys,sl,wstent_spl,1:
ws_test_lp:paddr=wstent.gandalf.xyz.com,105004,1,sys,lp,wstent_spl,1:\
:spooling-type=dpa:
WS_lps:paddr=wstent.gandalf.xyz.com,105004,1,sys,lp,wstent_spl,1: \
:spooling-type=dpa:

In general, whenever you create or delete an object (server, printer, queue), you need to update the name space on hosts where print system clients will be used. With an NIS-based name service, this happens automatically because the clients read up-to-date maps from the site NIS servers.

In addition, you need to update the name space on the server machines that communicate with other server hosts. For example, if a spooler on host A has queues that feed printers on host B, then the name space on both hosts A and B must contain entries for each other's objects. If a print system server host is not an NIS server in the domain, you will need to transfer a copy of its printers.conf file to the NIS server and push the printers.conf map whenever you make a change to its printer configuration.

If an NIS map already contains an object, and you delete the object (using the pddelete command) and then create the same object again (using the pdcreate command), the object is eliminated from the local file name space. This is because the name already exists in the NIS name space and servers do not create new name space entries if they already exist. Therefore, you need to use caution when you delete and recreate an object because you could lose the name space entry the next time you gather and push.

To avoid this situation:

3.3    LDAP Name Service

The LDAP Name Service offers an advantage over NIS by dynamically updating the name space when print objects are created or deleted. This section describes what is required to set up the LDAP client.

To set up the LDAP client:

  1. Create a user name and password on hosts containing spoolers and supervisors so that servers can modify the LDAP databases.

  2. Create or modify the /var/pd/config/apx.conf file so that it identifies LDAP as a name service you will use and to identify the LDAP server host. This file must reside on hosts containing spoolers and supervisors and on Advanced Printing clients.

3.3.1    Creating an LDAP Client Username and Password

Advanced Printing servers need a user name and a password to modify name entries on the LDAP server. The user name and password must be created after LDAP_hosts has been defined in the apx.conf file.

Create the user name and password using the pdldappw command:

# /usr/sbin/pdldappw

The command displays the current settings in the /var/pd/config/apx.conf file and prompts you to enter a user ID and password.

Contents of configuration file /var/pd/config/apx.conf:    
name-services = ldap   
LDAP-path=ou=advprint,o=Organization 
LDAP-hosts=toons.xyz.ayy.com  
LDAP User ID: advprintid 
LDAP password: *********

3.4    Creating or Modifying the apx.conf File

The /var/pd/config/apx.conf file contains information on name services you will use and contains information about the host system that is running the LDAP directory services. The following example shows a /var/pd/config/apx.conf file:

 name-services = file nis ldap
 LDAP_hosts  = system.abc.xyz.com 
 LDAP_path   = ou=organizational unit,o=organization

3.4.1    Protoserver Daemon

The protoserver is a print system daemon that works with the name services to enable a server process to access name and binding information of print system objects.

The protoserver is the primary RPC server in the print system. Clients and servers on remote hosts contact the protoserver on a server host to determine the RPC binding information for other print system server processes.

The print system installation procedure adds a line to the /etc/inetd.conf file so that the inetd daemon can automatically execute the protoserver when it is needed.