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.