--> "You do not need/want cups to run as root for this." <-- ----------------
Yes you do, at least in the context of this bug report. The bug report explicitely names an "RFC compliant LPD server". In case you are not familiar with RFC 1179 (which is the one that descibes LPD), please have a look yourself. But since I do not trust you that you do actually look at it, I'll give you a summary (despite my suspicion that you'll just ignore it): * Though RFC never made it into a "proposed standard", and always stayed on the "informational" level in the RFC standards track of IANA, LPD along the lines that 1179 summarized was widely implemented. * Unfortunately RFC 1179 makes the (stupid) recommendation that LPD clients "source ports must be in the range 721 to 731, inclusive". * This led to many strict LPD server implementations not accepting printjobs that do originate from other ports than 721 through 731. * This led to problems even with MS Windows printing (which became very slow and unperformant, when due to long TCP/IP timeouts only 11 possible source ports were not enough to supply for "many 1-page jobs quickly". That was "fixed" in NT-4.0 Service Pack 3, which introduced "non LPD source port printing". * SP3's measure in turn exerted more pressure on "compliant" LPD implementations to be patched for a more liberal handling of clients. * nowadays many of the still existing LPD servers do also accept job transmissions originating from other ports (especially ones that are above 1024 and can be used by non-root users) -- but there are still others out there.... * CUPS itself uses a liberal implementation, using by default "above 1024" source ports for its lpd:// backend. * If a CUPS admin finds that the target printer (or print server) insists on strict 721-731 source code compliance, he can force the printqueue's lpd:// backend into limiting itself to these source ports by adding the named "?reserve=yes" specification to the device URI --> "In this case, cups is a client which connects via high ports (over 1024) to lpd server." <-- ---------------- Hopefully you do see now that you was completely wrong with your statement. ---------------- Let me add a general advice/request/wish/suggestion for you to consider: Since Ubuntu packagers do heavily patch upstream sources to make them behave completely differently from what is officially documented, it would be not asked too much from you if you'd also actively participate in the CUPS forums. You could only learn from it, even very, very trivial things about printing, that you do not have much clue about currently. *If* you dare to patch (in effect, even _fork_ !!) CUPS, then you should at least be familiar with the design desicions taken, with the reasoning behind them, and the general use cases that lead to certain configuration defaults. But unfortunately, your participation over at CUPS.org in recent years was very thinly spread out. -- dapper cupsys can not print to rfc compliant lpd server, i.e. can not run as root https://launchpad.net/bugs/47773 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
