I'll reply to Bruce and Andy in a "conversational" manner, otherwise I feel things may get truly unintelligible with all those >, >> , >>>, etc. ------ There were two main subjects brought up in my OP.
Topic #1 ~~~~~~~~ - Alex wrote: In '/usr/lib/cups/filter/' the applicable filter in my case, 'rastertosamsungspl', MUST be owned by root:lp On 1.2.8 it was owned by alex:users (unprivileged folks) and everything was AOK On 1.5, 'lpstat -t' adds a warning (???): << File "/usr/lib/cups/filter/rastertosamsungspl" has insecure permissions (0100755/uid=1000/gid=100). >> Without the change to root:lp the printer will be dead. - Bruce (Dec 20, 2011 09:18:59 PM): On my system, the filters are mode 0555, root:root. Would that work? They are, after all, executable modules. I think the ownership was your problem. - Alex replies: Like I said, I had had no problems in 1.2.8: -rwxr-xr-x alex users 2008-03-24 rastertosamsungspl 1.1 True, security is of utmost importance nowadays (the no 1 story today is "China Hackers Hit U.S. Chamber [of Commerce]" If the Chambers didn't have _all_ files "root:root", serves them right!) but 1.2 It wouldn't've hurt a word like "Error: " in front of the "warning". This is a flame though, so disregard. - Andy (Dec 20, 2011 10:32:52 PM): I don't like to have anything in /usr that isn't owned by root. - Alex replies: If this is a preference, fine with me. However, let's not lose sight of the fact we're talking about a lousy printer filter here. To beat this subject to death, I have NO idea how the filter ended up as non-privileged during the 1.2.8 installation (which is not my habit, BTW). To think it sat there exposed like that on my machine all these years for the Chinese to exploit ... If it's a justifiable and useful recommendation, let's formalize it in a book/chapter somewhere so everybody can profit. Topic #2 ~~~~~~~~ - Alex wrote: In the latest BLFS book, chapter 43, CUPS-1.5.0, there's a << Note If you plan to use a USB printer with CUPS, do not enable the "usblp" driver as either built-in or as a module in your kernel configuration as it will cause the new CUPS USB backend to fail. /var/log/sys.log will contain entries similar to the following: kernel: [54631.796465] usb 4-1: usbfs: interface 0 claimed by usblp while 'usb' sets config #1 >> In my case, not exactly true. On kernel version 3.0.9 at least, your only "usblp" choice is <M> or nothing (i.e., there's no built-in), and on nothing the USB printer does not work (not surprisingly, I'd say) On <M> it does work (like it should), and speaking of "usbfs", you get something along the lines, - Bruce (Dec 20, 2011 09:18:59 PM): I have been using LFS 7.0 (3.0.4 kernel) and it can be built in. I can't check a more recent version right now, but I suspect the module requirement was because some dependent parameter was a module. - Andy (Dec 21, 2011 06:05:40 AM): I suspect that in your usb subsystem you've enabled something as a module and everything that depends on that can only be enabled as a module. CONFIG_USB_PRINTER=y works for me. I don't understand the note in the book. If the cups usb backend causes problems it seems to me that the correct response is to configure cups with --disable-libusb - Alex replies: Andy, what version kernel(s) are you talking about? On the subject kernel, 3.0.9, I have enabled, for better or worse (listed in order): Device Drivers > [*] USB support ---> <M> Support for Host-side USB [*] USB device filesystem (DEPRECATED) <M> USB Monitor <M> EHCI HCD (USB 2.0) support [*] Improved Transaction Translator scheduling <M> OHCI HCD support <M> UHCI HCD (most Intel and VIA) support <M> USB Printer support (!!!!!!) <M> USB Mass Storage support Many thanks for your comments, -- Alex -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
