kovar%husc4@talcott.harvard.edu (03/30/89)
I'm getting slighly fed up with the 4.0.1 release on the 386i and very fed up with Sun's hotline. So, we turn once again to Sun-Spots. Under 4.0, we had a 386i using a remote printer on another Sun. I just added the entry to /etc/printcap and everything worked fine. Uder 4.0.1, when I change printcap, lpc recognizes the change but lpr and lpq do not. I've also tried changing /etc/ypprintcap and remaking the maps with the same results. Any suggestions? Is there any way to prevent everything from looking at ypprintcap and go back to the old behavior? It's also fairly easy to get the following: lpc> stat lp: queuing is enabled printing is enabled no entries no daemon present lpc> down lp unknown printer lp lpc> Getting rid of all the yp maps for ypprintcap causes "Unable to find yp printcap map" or something similar. Removing /etc/printcap causes "Unable to find printer description file." ypcat printcap results in "No such map." lpr & lpq seem to use both /etc/printcap and the yp printcap map in some unfathomed method. Any help would be most appreciated. The second problem is getting quotas to work on the file server. My /etc/fstab entry looks like: /dev/roota / 4.2 rw 1 1 /dev/rootg /usr 4.2 rw 1 2 /dev/rooth /files 4.2 rw,quota 1 3 <------ /dev/sd0c /files1 4.2 rw,quota 1 4 <------ /export/tmp/localhost /tmp lo rw 0 0 /export/var/localhost /var lo rw 0 0 /export/cluster/sun386.sunos4.0.1 /usr/cluster lo rw 0 0 /export/local/sun386 /usr/local lo rw 0 0 And when the system boots, I get the standard "Unknown option QUOTA" which I am accustom to ignoring. But my mtab looks like: /dev/roota / 4.2 rw 1 1 /dev/rootg /usr 4.2 rw 1 2 /dev/sd0c /files1 4.2 rw,quota 1 4 <------ /dev/rooth /files 4.2 rw 1 3 <------ /export/local/sun386 /usr/local lo rw 0 0 /export/cluster/sun386.sunos4.0.1 /usr/cluster lo rw 0 0 /export/var/localhost /var lo rw 0 0 /export/tmp/localhost /tmp lo rw 0 0 The "quota" file is at the root of both of the filesystems in question. Why is it not taking on /files when it will on /files1? Does it not like "rooth" for some reason and it would prefer sd1h? -David Kovar kovar@husc4.harvard.edu