> -----Original Message----- > From: Kurt Pfeifle [mailto:[EMAIL PROTECTED]]
> *Seems*... > > I tell you what mine is doing: It *uses* the printing system. Okay. I know the one Linux Journal talked about a while back did not -- it was just a shell script that was run as a 'print command'. This has some advantages, one being it's a lot easier to send a popup notification, since you already have the client IP. My old script, the one that was an lpd input filter, had to go through some gyrations to figure out the IP associated with the username that the job was submitted under. > My printing > system is CUPS, the most flexible one of them all. I use a bash shell > script which is made to work as a CUPS "backend". This sounds interesting, and I may look into it if I can't figure this out. I was hoping to get rid of the added complication of the printing system altogether, since it shouldn't really be necessary for what I'm trying to do. There are NO physical printers on the system, so running a full-blown spooling and printing system doesn't get me anything but configuration headaches and another running service for someone to exploit. And frankly, editing /etc/printcap gives me a raging headache. ;) > > I didn't post that > > information because it didn't seem relevent to the question. > > You yourself indicated that it is relevant because you said after > the upgrade your script stopped working... Right, but that script isn't the same one I'm trying to use now. That script was an lpd input filter, linked in through /etc/printcap. This one is run directly from Samba. It does work, except for the fact that Samba never creates a temporary file with the print job in it. This makes me skeptical that CUPS will work, either -- where would it get the data from? I know under LPRng, Samba simply created a temporary file, then called lpr on it. That won't work if there's no temporary file created. > And, BTW, you shouldn't call people any names, who are giving their > private time for free to help people who seem to have > problems in their profession -- or be prepared to get no answer at all. I'm sorry, but if someone is rude to me I tend to return the favor. You may want to go back and look at the tone of voice you used in your original reply to me. I *do* appreciate the help, but I don't appreciate being treated like an idiot in the process. > * Samba has a great little utility, which lets you increase > and decrease the debuglevel "on the fly", without editing > and reloading the smb.conf or stopping and starting the > daemon: > > "smbcontrol smbd debuglevel" # tells you the current debuglevel > "smbcontrol smbd debug 3" # set the debuglevel to 3 Good idea. I will give this a try after business hours. Right now there's so much traffic on the system that the debug output is overwhelming at level 3. I'll keep your other suggestions, and use them if I can't get this working as-is. I really feel like it shouldn't be necessary to build a whole CUPS configuration just to do this, though. Other examples I've seen for creating PDF printers didn't. -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
