Control: tags -1 +moreinfo
Hi Julian, and thanks for your bugreport,
Le dimanche, 25 octobre 2015, 23.26:07 Julian Gilbey a écrit :
> I've flagged this as important because it could lead to a DoS attack
> potentially. (It filled up my whole disk partition until I located
> the source of the problem.) I am utterly bemused as to what might be
> causing this problem....
>
> Situation: I have a Samsung ML-1610 printer connected to a machine
> running Debian testing. I can print from the server with no problem.
> However, I have tried printing to it from another Debian testing
> machine and from an Apple MacBook running OSX 10.11, and they both end
> up flooding the log file.
Which log file ? /var/log/cups/error_log ? What disk space does this
partition have? How big was the file when you hit the disk space limit?
> This must have started relatively recently, as I certainly used to be
> able to print from a remote computer. I have tried using the foomatic
> ppds and also tried installing the suld packages from
> http://www.bchemnet.com/suldr/ to no avail.
You should use the 'splix' driver as shipped in 'printer-driver-splix'.
As far as I could tell, it is supposed to work fine for your printer.
> My cupsd.conf file reads as follows, heavily based on the sample
> configuration file:
>
> -----
> # Log general information in error_log - change "warn" to "debug"
> # for troubleshooting...
> LogLevel debug
This statement certainly doesn't help keeping the log small. :)
> Part of the very long error_log file reads as follows, showing the
> whole of "Client 106"; this pattern is repeated again and again with
> different client numbers. The most interesting (though perhaps
> misleading) comment is that no authentication data is provided.
This looks weird indeed. That said, can you reproduce this with only
Debian packages (cups + printer-driver-splix configured for that
printer) ?
I'm not entirely dismissing an error from CUPS though: Steve Langasek
reported the same bug on Ubuntu:
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1421252
It looks like there's a weird {un-,}authentication loop happening there.
Cheers,
OdyXAttachment:
signature.asc
Description: This is a digitally signed message part.