Re: Request for comments: new `lpd' suite feature
At 9:25 PM -0700 7/14/00, Thomas D. Dean wrote: How would this work with printers on local networks? Say, a print server 192.168.1.73? If you do not have a special DNS entry for that printer, then this new synthetic-printcap option would do nothing for you. In other words, you would continue doing your printcap file exactly the way you do it now. --- Garance Alistair Drosehn = [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Institute To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Request for comments: new `lpd' suite feature
At 12:09 AM -0400 7/15/00, Louis A. Mamakos wrote: I almost hate to bring this up, but I think the unnamed-here proposed replacement for our lpd allows you to set your PRINTER environment variable to something like [EMAIL PROTECTED] louie For what it's worth, I think that feature is a little too helpful, and I would not want that ability on our (RPI) public unix workstations. I do want some capability to specify a hostname, but not a wide-open capability to specify any hostname. --- Garance Alistair Drosehn = [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Institute To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Request for comments: new `lpd' suite feature
On Sun, 16 Jul 2000 16:46:58 -0400, Christopher Masto [EMAIL PROTECTED] said: Huh? Security through ignorance? Remember that `lpr' is setuid-root and uses a ``privileged'' port for its communications. Many sites may still be using trusted-host ``authentication'' internally, and LPRng's ``feature'' may enable a compromise of some such service. (Got enough scare quotes there?) -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Request for comments: new `lpd' suite feature
On Sun, Jul 16, 2000 at 08:15:05PM -0400, Garrett Wollman wrote: On Sun, 16 Jul 2000 16:46:58 -0400, Christopher Masto [EMAIL PROTECTED] said: Huh? Security through ignorance? Remember that `lpr' is setuid-root and uses a ``privileged'' port for its communications. Many sites may still be using trusted-host ``authentication'' internally, and LPRng's ``feature'' may enable a compromise of some such service. (Got enough scare quotes there?) That is indeed something I failed to consider. I suppose it would be necessary to have some control over that feature in some environments. I just find it incredibly convenient to be able to install LPRng on a bunch of client machines and just rm /etc/printcap, set $PRINTER, and be done with it. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Request for comments: new `lpd' suite feature
Christopher Masto [EMAIL PROTECTED] writes: On Sun, Jul 16, 2000 at 08:15:05PM -0400, Garrett Wollman wrote: On Sun, 16 Jul 2000 16:46:58 -0400, Christopher Masto [EMAIL PROTECTED] said: Huh? Security through ignorance? Remember that `lpr' is setuid-root and uses a ``privileged'' port for its communications. Many sites may still be using trusted-host ``authentication'' internally, and LPRng's ``feature'' may enable a compromise of some such service. (Got enough scare quotes there?) That is indeed something I failed to consider. I suppose it would be necessary to have some control over that feature in some environments. I just find it incredibly convenient to be able to install LPRng on a bunch of client machines and just rm /etc/printcap, set $PRINTER, and be done with it. as I remeber me, the same thing is possible under newer Solaris boxes. Cyrille. -- home:mailto:[EMAIL PROTECTED] Supprimer "%no-spam" pour me repondre. work:mailto:[EMAIL PROTECTED] Remove "%no-spam" to answer me back. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Request for comments: new `lpd' suite feature
Around here, we have a convention that each printer has a record in
the DNS for printername.lpd-spooler which points to the print server for
that printer. It occurred to me that, if there are no local printers,
no additional information is needed for lpr and lpd to operate -- thus
obviating the need for that pesky `/etc/printcap' file which never
seems to be stay up-to-date. Here is some code which I am planning to
commit soon (after I've actually tested it) which does precisely
that. The patch also contains a few bug fixes and enhancements for
chkprintcap(8). (I've already noticed some bugs in reading this
patch.)
Index: chkprintcap/chkprintcap.8
===
RCS file: /home/cvs/src/usr.sbin/lpr/chkprintcap/chkprintcap.8,v
retrieving revision 1.3
diff -u -r1.3 chkprintcap.8
--- chkprintcap/chkprintcap.8 1999/08/28 01:16:46 1.3
+++ chkprintcap/chkprintcap.8 2000/07/14 19:35:10
@@ -26,7 +26,7 @@
.\" SUCH DAMAGE.
.\"
.\" $FreeBSD: src/usr.sbin/lpr/chkprintcap/chkprintcap.8,v 1.3 1999/08/28 01:16:46
peter Exp $
-.Dd November 30, 1997
+.Dd July 14, 2000
.Dt CHKPRINTCAP 8
.Os
.Sh NAME
@@ -34,7 +34,7 @@
.Nd check validity of entries in the print spooler database
.Sh SYNOPSIS
.Nm chkprintcap
-.Op Fl d
+.Op Fl ds
.Op Fl f Ar printcap
.Sh DESCRIPTION
.Nm Chkprintcap
@@ -60,6 +60,13 @@
.Sq Li sd=
capability
.Pc .
+.It
+Every spool directory is owned by the daemon user
+.Po
+.Sq Li du#
+capability
+.Pc ,
+and is only writable by that user.
.El
.Pp
.Nm Chkprintcap
@@ -68,6 +75,15 @@
entire file is scanned.)
.Pp
If the
+.Fl s
+flag is used,
+.Nm chkprintcap
+will
+.Dq synthesize
+a printer database, as described in
+.Xr lpd 8 .
+.Pp
+If the
.Fl d
flag is given,
.Nm chkprintcap
@@ -79,6 +95,13 @@
.Sq Li du=
capability in the database (default 1, which corresponds to user
.Sq Li daemon ) .
+.Sh FILES
+.Bl -tag -width "/var/spool/output"
+.It Pa /var/spool/output
+default directory scanned for spool directories by the
+.Fl s
+option.
+.El
.Sh SEE ALSO
.Xr lpr 1 ,
.Xr printcap 5 ,
@@ -89,8 +112,6 @@
command was written by
.An Garrett A. Wollman Aq [EMAIL PROTECTED] .
.Sh BUGS
-Not enough sanity-checking is done. At a minimum, the ownership and
-mode of the spool directories should also be checked. Other
-parameters whose value could cause
+Other parameters whose value could cause
.Xr lpd 8
to fail should be diagnosed.
Index: chkprintcap/chkprintcap.c
===
RCS file: /home/cvs/src/usr.sbin/lpr/chkprintcap/chkprintcap.c,v
retrieving revision 1.5
diff -u -r1.5 chkprintcap.c
--- chkprintcap/chkprintcap.c 2000/05/26 02:08:31 1.5
+++ chkprintcap/chkprintcap.c 2000/07/14 20:23:18
@@ -1,5 +1,5 @@
/*
- * Copyright 1997 Massachusetts Institute of Technology
+ * Copyright 1997, 2000 Massachusetts Institute of Technology
*
* Permission to use, copy, modify, and distribute this software and
* its documentation for any purpose and without fee is hereby
@@ -28,7 +28,7 @@
*/
static const char copyright[] =
- "Copyright (C) 1997, Massachusetts Institute of Technology\r\n";
+ "Copyright 1997, 2000 Massachusetts Institute of Technology\r\n";
static const char rcsid[] =
"$FreeBSD: src/usr.sbin/lpr/chkprintcap/chkprintcap.c,v 1.5 2000/05/26 02:08:31
jake Exp $";
@@ -38,7 +38,7 @@
#include err.h
#include errno.h
-#include grp.h
+#include pwd.h
#include stdio.h
#include string.h
#include stdlib.h
@@ -57,6 +57,15 @@
static int problems; /* number of problems encountered */
+#ifndef SPOOL_DIR_MODE
+#defineSPOOL_DIR_MODE (S_IRUSR | S_IWUSR | S_IXUSR \
+| S_IRGRP | S_IXGRP | S_IROTH | S_IXOTH)
+#endif
+#define ALL_MODE_BITS (S_IRUSR | S_IWUSR | S_IXUSR \
+| S_IRGRP | S_IWGRP | S_IXGRP \
+| S_IROTH | S_IWOTH | S_IXOTH \
+| S_ISUID | S_ISGID | S_ISVTX)
+
/*
* chkprintcap - check the printcap file for syntactic and semantic errors
* Returns the number of problems found.
@@ -64,13 +73,14 @@
int
main(int argc, char **argv)
{
- int c, error, makedirs, more;
+ int c, error, makedirs, gotone;
struct printer myprinter, *pp;
+ do_synthesize_printcap = 0;
makedirs = 0;
pp = myprinter;
- while ((c = getopt(argc, argv, "df:")) != -1) {
+ while ((c = getopt(argc, argv, "df:s")) != -1) {
switch (c) {
case 'd':
makedirs = 1;
@@ -80,6 +90,10 @@
setprintcap(optarg);
break;
+ case 's':
+ do_synthesize_printcap = 1;
+ break;
+
default:
usage();
}
@@ -87,12 +101,13 @@
if (optind != argc)
usage();
+
+ gotone = firstprinter(pp,
Re: Request for comments: new `lpd' suite feature
At 5:39 PM -0400 7/14/00, Garrett Wollman wrote: Around here, we have a convention that each printer has a record in the DNS for printername.lpd-spooler which points to the print server for that printer. It occurred to me that, if there are no local printers, no additional information is needed for lpr and lpd to operate -- thus obviating the need for that pesky `/etc/printcap' file which never seems to be stay up-to-date. and in the update, he wrote comments which said: This is intended for large sites where distributing the printcap file is a pain; it will infer from the presence of spool directories in _PATH_DEFSPOOLDIR a printcap entry with rm=%s.lpd-spooler and rp=%s (following the convention used at MIT-LCS where the author currently works). I can sympathize with the idea of getting rid of /etc/printcap, but I admit this strategy perplexes me. How is it easier for you to keep the "presence of spool directories" up to date, than it is to keep /etc/printcap up-to-date? Speaking for my lpd use here at RPI, it is MUCH easier for us (RPI) to keep printcap files in sync than it is to rely that the contents of a directory on the local hard disk is magically correct. Further, if you really CAN keep that up-to-date easier, then it seems to me pretty trivial to write some perl script or routine in chkprinter which simply creates /etc/printcap from those directories. From my reading of your update, you have this "synthetic" printcap file which lpd knows about, but you never write that out anywhere. At least at RPI, we do have other processes which check the /etc/printcap file to make decisions. If that file does not exist, or is not accurate, then those other processes will not work right. I would also say that here at RPI (at least), we have plenty of things in the printcap entries which are not covered by this strategy. Most notably, printer aliases. Every printer we have has multiple names. How are multiple names handled in this situation? Obviously I am just writing the first things which come to my mind in ten minutes of me looking at this update (late on a friday evening!), but it strikes me that this is too much a matter of codifying into freebsd's lpd something which is rather specific to MIT practices. This may very well be useful for other people too, but I can't imagine how I would make any use of this at RPI. That by itself is not important, but (if I am reading your update correctly) it means that there are now "two ways" that the code will deal with printcap files. When someone makes an update (such as adding new fields to 'struct printer'), they will have to be sure to make the update in both places. This makes me queasy. Also, I wonder how all this fits in with the discussion in -arch which has been going (on and off) about replacing lpr in FreeBSD with lprNG. That's not my idea, but I do know I have been holding off some lpr/lpd updates of my own until I have some idea what is going to happen with that. If freebsd is going to switch to lprNG, then this is just one more little oddity which (I think) lprNG will not handle quite the same way. Me, I am interested in ways to make printcap files more automated, but this strategy which may work well in MIT's environment would not make any sense in ours... Disclaimer Reminder: I've only SKIMMED through the actual update, so I may misunderstand what it's doing... Apologies if I have done that. --- Garance Alistair Drosehn = [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Institute To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Request for comments: new `lpd' suite feature
I almost hate to bring this up, but I think the unnamed-here proposed replacement for our lpd allows you to set your PRINTER environment variable to something like [EMAIL PROTECTED] louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Request for comments: new `lpd' suite feature
How would this work with printers on local networks? Say, a print server 192.168.1.73? tomdean To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
