SUMMARY: How do I add /etc/printcap to NIS?

From: Stefan Frick (etxstfr@helix.ericsson.se)
Date: Thu Jul 08 1993 - 16:00:19 CDT


Just as I suspected.... It wasn't that easy!

Well, the replies varied from 'No, it cannot be done!' to 'Yes, but it will cost you a lot of money' (and perhaps a lot of time and headache?)

The alternatives seems to be:

1. A product from Sun Cunsulting called NISLPD (or something like that)

2. Replace the original lpr, lpc and lpq with the Berkeley stuff and modify it.

3. Put /etc/printcap in a NFS-reachable directory and replace the original with a link.

4. Use 'rdist' to distribute an updated /etc/printcap to all hosts.

5. Put /etc/printcap in a NIS-map and let the client re-create /etc/printcap when it
   reboots. (Hmm... interesting!)

6. Migrate to Solaris 2.x, NIS+ seems to have this feature from the very beginning!

Thanks to all who replied, your names are included below!

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

David J. Bianco <bianco@cs.odu.edu> writes:

SunOS (except for on 386i's and Solaris 2.x) does not support NIS printcaps.
None of the utilities will look into YP for the entries, so you are pretty
much screwed. Sun will sell you a package to do this (I don't remember the
name of it, CONSULTLP or something) which was developed by sun consulting..

        David

Badri Pillai <Badri.Pillai@ecrc.de> writes:

We do use printcap which is NISed for all the clients.
whenever the client reboots it creates a printcap file
from NIS.

I don't know if you have already enough replies, esle
let me know I'll send you examples how we do it.

regards,

badri

bernards@ECN.NL (Marcel Bernards) writes:

You can make a dbm map if you make it a oneliner per printer instead of the `\` stuff

LP:blabla:if=???.....:
LP2:.....:
etc.

But I doubt if you get your LPD daemon working, because it is deaf for NIS maps.
You must hack into lpd sources or PD implementations for it (plp) and hack dbm() stuff in them.

Steve Hanson <hanson@pogo.fnal.gov> writes:

There's no way to do this. None of the printing utilities know anything
about YP maps. You could certainly build an NIS map, but nothing
will pay any attention to it.

feldt@phyast.nhn.uoknor.edu (Andy Feldt) writes:

   Sorry, but you are out of luck (unless you are using Sun 386i PCs!).
It takes more than generating an NIS map for the map to be useful - it
also requires that the relevant software try to use such a map. None
of the lpr software does this, so unless you are willing to write your
own, it can not be done.

perryh@pluto.rain.com (Perry Hutchison) writes:

Getting the map built and installed is the least of the problems. The
big one is getting lpr and company to consult NIS instead of (or in
addition to) the local /etc/printcap.

If you have SunOS source, this is probably not all that tough. If not,
I can think of three approaches offhand:

1. Check with Sun Consulting -- I think they may have already done it;

2. Replace SunOS lpr, lpc, and lpq with the Berkeley Net-2 versions,
    and hack on those sources;

3. Try something along the lines of the named-pipe hacks that people use
    to keep track of finger or to change their .sig after each posting --
    I think this is in the FAQ for comp.unix.questions .

kevin@uniq.com.au (Kevin Sheehan) writes:

And you have to have an lpd that looks there... Sun has a Consulting
Special called CONSULT-NISLPD that does NIS support for lpd, as well
as support for terminal servers as printers.

You can always do what they did - take the 4.3 lpd/lpr and whack the
support in yourself.

gordonr@nms.otc.com.au (Gordon Rowell) writes:

I have included our part of the NIS Makefile, BUT, it won't help you unless you also get lpd, lpr, lpc, and so on to talk to NIS. The Sun supplied ones don't,
so there is no point in making an NIS map out of printcap.

However, there is a Sun Consulting Special - NISLPD which can be obtained from
your local Sun sales rep. We use it on our (fairly large) network, and we
have centralised printer administration through NIS. NISLPD is also nice in
that it creates spool directories and log files when someone first tries to
use the printer. The extract from the NIS Makefile comes straight out of NISLPD.

(Extract from the NISLPD Makefile deleted to save bandwidth... Thanks anyway Gordon!)

peters@nms.otc.com.au (Peter Samuel) (Same company as above! G'day Peter!)

Adding printcap to NIS is only half the story. All the lpr stuff needs
to be NIS aware (which it isn't).

Sun have a consulting special called CONSULT-NISLPD. This suite of
programs replaces all the lpr files - lpr, lpd, lpc, lpq etc etc etc.
The new programs are all NIS aware and use both /etc/printcap and the
printcap.byname map.

They take advantage of a new field in the printcap 'tc' which, like
its termcap counterpart, is a continuation entry. It allows you to set
up generic printers - eg sparc printers - and then have smaller
specific printer entires which will reference the generic entries.

Re: makedbm - yes the resulting files will look strange. Think of dbm
files as single line entries. You're taking a list of lines from your
printcap file which in reality are continuations of the one line (note
the trailing backslashes) and storing them as a dbm entry. Whenever
you display the entry it will appear as a single line of colon
separated fields.

micky@ejv.com (Micky Liu) writes:

It is not a simple thing, but this is what we decided to do...

We made two NIS maps, printcap which contains the regular entries for all
machines and printservers which is keyed by hostname with entries for
those machines which actually support directly connected printers. Then
we created the following script which we run from /etc/rc before lpd is
started. Basically it generates a new printcap file from information
stored in the NIS maps when the machine is coming up.

---------------------------------------------------------------------

#!/bin/sh
MAP=printcap
if [ "`ypwhich -m $MAP 2>/dev/null`" ]
then
        if [ -r /etc/printcap.local ]
        then
                cat /etc/printcap.local > /etc/printcap
        else
                cp /dev/null /etc/printcap
        fi
        if [ "`ypwhich -m printservers 2>/dev/null`" ]
        then
                for subentry in `ypmatch \`hostname\` printservers 2>/dev/null \
                | tr ':' ' '`
                do
                        ypmatch $subentry printservers
                done 2> /dev/null | sed 's/::/:\\\
        :/g' >> /etc/printcap
        fi
        ypcat $MAP | sed 's/::/:\\\
        :/g' >> /etc/printcap
        for sd in `sed -n 's/.*sd=\([^:]*\):.*/\1/p' /etc/printcap`
        do
                if [ ! -d $sd ]
                then
                        mkdir -p $sd
                        chown daemon.bin $sd
                fi
                sdlog="${sd}/log"
                if [ ! -f $sdlog ]
                then
                        touch $sdlog
                        chown daemon.bin $sdlog
                        chmod 666 $sdlog
                fi
        done
fi

charlesb@nimrod.ta.oz.au (Charles Butcher) writes:

As far as I know, standard lpr/lpd does not consult the NIS, it only
reads /etc/printcap. So even if you can get printcap propagated as an
NIS map it probably won't do what you are expecting.

Sun offer a so-called "Consulting Special" called CONSULT-NISLPD which
they ask a disgusting amount of money for (local asking price is
AUD2850), considering how minor the change is, and that they offer no
warranty or support for it!! This product adds NIS printcap capability
and limited support for attaching printers to terminal servers.

I told Sun to take a hike ($2850!! No way!!) and started looking into
alternatives. You can get source off the internet for the Berkeley
lpr/lpd which you could modify if you wanted to. There is also a
package called PLP on several archive sites.

A quick fix I thought of would be to maintain a master printcap file in
an NFS exported directory on a server (say /usr/local/etc) and change
all the clients to have a symbolic link from /etc/printcap to
/usr/local/etc/printcap.

If you hear of any better solutions please summarise!!

leon@orbot.co.il (Leon Koll) writes:

Hello, Stefan,
i hope this will help you.
Regards,
Leon
____________________________________________________
 
Leon Koll leon@orbot.co.il
System Administrator
Orbotech Ltd. (972) 8-423-664
Yavneh, Israel
 
____________________________________________________

----- Begin Included Message -----

>From sun-managers-relay@ra.mcs.anl.gov Tue Dec 15 20:03:26 1992
To: sun-managers@eecs.nwu.edu
Subject: SUMMARY: Printcap NIS file conversion

Original post:

--------------------------------------------------------------------------------

> System: Sparc 2 running SunOS 4.1.2.
>
> Does anyone know a relatively easy way to turn the /etc/printcap file into
> a NIS map ?
>
> I have RTFM'd and it does not seem like an easy matter. I can run makedbm and
> create the .pag and .dir files but when I go to yppush them I get an error
> indicating that the map does not exist, even though both printcap.pag and
> princap.dir.
>
> If anyone can point me in the direction of further reading or give me a cook
> book approach to this I would appreciate it.
>
> As usual I will summarize.

--------------------------------------------------------------------------------

The speed of responses from this list never ceases to amaze me. I got three
replies all of which more less said the same thing - You Can't Do It - with
stock Sun 3 or 4 systems.

There is a package called CONSULT-NISLPD available from the SUN consulting
group that modifies all the tools that reference the printcap file. I am not
sure that I can afford to buy that so I guess I will just have to maintain a
printcap file on all the systems around here.

I have included the text of the replies below since there were only 3.

------------------------------- Replies -------------------------------------

buy CONSULT-NISLPD.

in order to make the printcap file NIS-based, you need to modify
*all* of the tools that use it or reference it: lpr, lpd, lprm, lpq.
sun's consulting group created the above-named special that does
just that.

the error you're getting has more to do with new map creation than
the actual map itself. when you create a new map, you need to "pull"
it from the NIS slave server before you do a push -- a push only
works if the client already has the map. check out "ypxfr" for
doing a pull.

--------------------------------------------------------------------------------

As far as I know this is not supported on Sun4* and Sun3*.
It was/is only implemented on Road Runner (Sun386i) !

--------------------------------------------------------------------------------

There is a Sun Consulting Special "CONSULT-NISLPD" which allows lpr to
access the printcap via nfs. Out of the box SunOS 4.x does not do this
(except for the 386i).

--------------------------------------------------------------------------------

There are 5 additional answers to the query.

1) use rdist.
2) If there is a commonly mounted file system, put the printcap file in
   there and create a symbolic link in the /etc directory to point at it.
3) Solaris 2.1 is supposed to incorporate the NIS printcap feature.
4) Get the lpr stuff from Berkeley.
5) try the plp stuff, available via anon ftp from ftp.dcs.ed.ac.uk, look for
   something like pub/plp.

Larry Chin {larry@cch.com} CCH Canadian Ltd.
System Administrator 6 Garamond Court
Research and Development Don Mills, Ontario.
(416) 441-4001 ext. 349 M3C 1Z5

----- End Included Message -----

ebumfr@ebu.ericsson.se (Mike Rembis 66520) writes:

As far as I know, it cannot be done.

That's why they created NIS+ .... ;-)

Mark Herberger <mherberg@eve044.cpd.ford.com> writes:

I believe that this feature (NIS printcap) was dropped after 4.0.3

++++++++++++++++++++++++++++ END OF SUMMARY +++++++++++++++++++++++++++++++++++++++++++



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:08:00 CDT