After reading the discussion about printer "drivers" (I use quotes due to the different definitions of the term - obviously we aren't talking about kernel drivers here) I've been thinking about how to manage such things. I've used proprietary printer drivers in the past myself, printers are things that sometimes just get added to a network without the sysadmin being consulted (it works for all the Windows systems) and then we are stuck with making them work for so many years that the manufacturer stops providing software updates and it needs shared objects that aren't even supported any more. It seems to me that Docker and similar technologies are a good solution to this. They can encapsulate the shared objects needed (a driver from a badly made .deb or from a .tar.ge won't stop "apt autoremove" from removing things it needs), and deal with architectural issues (I probably don't really need the full overhead of multi-arch just to have an i386 printer driver running on an AMD64 system). Docker etc all have security features that cups lacks which are needed to prevent the (presumably badly written) printer driver from having exploitable security flaws or from just using all memory or disk space. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
On Tue, May 22, 2018 at 11:13:05PM +1000, russell@coker.com.au wrote:
It seems to me that Docker and similar technologies are a good solution to this. They can encapsulate the shared objects needed (a driver from a badly made .deb or from a .tar.ge won't stop "apt autoremove" from removing things it needs), and deal with architectural issues (I probably don't really need the full overhead of multi-arch just to have an i386 printer driver running on an AMD64 system). Docker etc all have security features that cups lacks which are needed to prevent the (presumably badly written) printer driver from having exploitable security flaws or from just using all memory or disk space.
Docker can have difficulty running really old distros. Some time ago, I had to create a frankenwheezy docker container (wheezie + libc6 from jessie) in order to keep an old wheezy app running after an upgrade of the docker host. http://blog.taz.net.au/2016/09/16/frankenwheezy-keeping-wheezy-alive-on-a-co... BTW, I tried something similar to keep an old etch container running. Couldn't get it working, no matter what I tried. Ended up building a full VM for it to run with KVM. A full VM is a little more runtime overhead than docker (but if all it's running is a print server & print driver, it won't need much RAM or CPU), but it's completely isolated from the host machine so host upgrades will never break the VM (unless they break KVM itself, of course). Cerainly easier to keep working than building new docker images whenever something breaks. Also, a VM or container is a damn good way of keeping proprietary software isolated from the rest of your system. Even if they're not actively malicious spyware, the code is probably crap - just looking at some of the install and startup scripts by proprietary developers is a freaking horror show. I wouldn't expect the binary-blob compiled code to be any better. Anyway, create the VM, get it running, install and configure the proprietary crapware and when it's working, take a snapshot. If it suicides with a buggy startup or whatever script (sadly more common that you'd think - usually because the script doesn't double-quote variables or check that the variable has a sane value before blithely 'rm -rf'-ing with it) then rollback to the snapshot. craig -- craig sanders <cas@taz.net.au> BOFH excuse #262: Our POP server was kidnapped by a weasel.
I've essentially done a version of this for the scanner drivers for a brother printer - printer works fine, scanner is a special kind of beast... wine turned out to work - just... it was a large amount of trial and error to determine which utility of the dozen or so was the actual printer manager - once that was worked out it worked just fine... I don't think it is a permanent solution though - it's rather winXP still... On 23 May 2018 at 00:07, Craig Sanders via luv-main <luv-main@luv.asn.au> wrote:
On Tue, May 22, 2018 at 11:13:05PM +1000, russell@coker.com.au wrote:
It seems to me that Docker and similar technologies are a good solution to this. They can encapsulate the shared objects needed (a driver from a badly made .deb or from a .tar.ge won't stop "apt autoremove" from removing things it needs), and deal with architectural issues (I probably don't really need the full overhead of multi-arch just to have an i386 printer driver running on an AMD64 system). Docker etc all have security features that cups lacks which are needed to prevent the (presumably badly written) printer driver from having exploitable security flaws or from just using all memory or disk space.
Docker can have difficulty running really old distros. Some time ago, I had to create a frankenwheezy docker container (wheezie + libc6 from jessie) in order to keep an old wheezy app running after an upgrade of the docker host.
http://blog.taz.net.au/2016/09/16/frankenwheezy-keeping- wheezy-alive-on-a-container-host-running-libc6-2-24/
BTW, I tried something similar to keep an old etch container running. Couldn't get it working, no matter what I tried. Ended up building a full VM for it to run with KVM.
A full VM is a little more runtime overhead than docker (but if all it's running is a print server & print driver, it won't need much RAM or CPU), but it's completely isolated from the host machine so host upgrades will never break the VM (unless they break KVM itself, of course). Cerainly easier to keep working than building new docker images whenever something breaks.
Also, a VM or container is a damn good way of keeping proprietary software isolated from the rest of your system. Even if they're not actively malicious spyware, the code is probably crap - just looking at some of the install and startup scripts by proprietary developers is a freaking horror show. I wouldn't expect the binary-blob compiled code to be any better.
Anyway, create the VM, get it running, install and configure the proprietary crapware and when it's working, take a snapshot. If it suicides with a buggy startup or whatever script (sadly more common that you'd think - usually because the script doesn't double-quote variables or check that the variable has a sane value before blithely 'rm -rf'-ing with it) then rollback to the snapshot.
craig
-- craig sanders <cas@taz.net.au>
BOFH excuse #262:
Our POP server was kidnapped by a weasel. _______________________________________________ luv-main mailing list luv-main@luv.asn.au https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
-- Dr Paul van den Bergen
participants (3)
-
Craig Sanders -
Paul van den Bergen -
Russell Coker