OK - not sure how much anyone here can be of help - given I’m just about the only user here of RPM based distros…
Unable to patch a pair of CUPS servers - due to multi-lib… they’re running Oracle Linux 7… the only enabled repos are Oracle’s public yum, and epel (via the mirror hosted at aarnet).
I suspect what’s happened, I’ve installed some i386 libraries when I’ve installed packages for Brother printers… DAMN! But now that’s broken yum completely… Can’t update…
I’ve cloned the non-prod one to a sandpit instance, and I’m going to try purging i386 - then install later drivers for these brother printers :
mfcj6930
mfcl3745
I’m assuming these are Brother printers - as that naming convention looks familiar…
Wish me luck… The damnedest thing is - I can’t really test properly… All theBbrother printers are hundreds of kilometres away, some over a thousand! West Australia can fit Texas in the small change pocket of its jeans
Strike that! I’m just going to tell the customer we can’t patch… The VERY VERY latest drivers from the vendor - come as i386 rpm files - there’s NO x86_64…
I use i386 drivers (as .deb file) for my Brother printer. They work in 64 bit Linux provided it has multiarch … at least it works for me in Debian, Devuan, MX, and Void.
You should be able to use the 32bit .rpm drivers. There is not much difference between .rpm and .deb… they are just archives containing tarfiles and some scripts.
It might be possible to take the drivers out of yum control and install them somewhere else like /usr/ local. You might need some links from /usr/lib to /usr/local/lib so that cups can find all the stuff it needs to make print. … Not easy, and even less easy at a distance.
When you’re in a team - you can’t do stuff like that… Stuff has to be pretty close to stock standard, soon as you start veering away from that you end up with nightmare stuff… that’s a pretty tall ask when customers refuse to pay for licenses - and - the time to implement - things like SOE/MOE for Linux server builds and configuration management tools (like Ansible or Puppet). Fair enough I’m the main “primary” for this customer, but, what happens in the “hit by bus” scenario? Yeah - I document it - sure - but what happens when someone else like me comes along, assumes there’s no doco (which I do all the time) and break it?
Anyway - I’ve got a sandpit, I’m going to try removing and purging those i386 and i686 packages then take a look at what happens - maybe update without those brother drivers, then try to re-install them.
If that doesn’t work I’m just going to put a big red X next to both boxes : “we don’t patch these”… There’s already a whole fleet of servers we don’t patch 'cause the application vendor only supports their product on platform X, version Y, release Z - and another platform that’s 100% controlled and stood up by a KVM deployment suite that enforces configurations, patching it would break everything.
Anyway - I’ve got a sandpit, I’m going to try removing and purging those i386 and i686 packages then take a look at what happens - maybe update without those brother drivers, then try to re-install them.
That makes sense. Note purge does not always do a clean job
I dont understand why those brother drivers would upset the packsge system. they do put files in /usr/lib or /usr/lib64 that are not controlled by the package system, but the only thing that complains about that for me is ldconfig
Update : yum remove *i686 seemed to work - and it’s now letting me “yum update” - I always save the first run of “yum update” to a transaction log, then replay that transaction log. Once it’s done, I’ll reboot and see about re-adding those Brother RPM files… Note - the versions I installed yonks ago, are the same ones I downloaded from Brother - so Brother haven’t updated their drivers for these for a few years, at least.
yum update --assume-no
(will create a transaction log in /tmp, but won’t update anything)
then :
yum -y load-transaction $PATH/$TransActionLog
This feature is exceptionally useful when e.g. patching Test in Week 1, then Prod the week after - run “yum update --assume-no” everywhere, and you’re applying the same set of patches at that point in time across the whole fleet of servers. I’ve no idea if Debian or Ubuntu or other DEB flavours have that feature or not, don’t manage enough of them for it to be a major issue (which is not quite true - as I “manage” a bunch of them at home!).
And that seemed to work. But still have to verify if the CUPS test pages came out 1500 km away in the three regional offices.
One thing I hate about CUPS server configuration - all the access stuff you have to tweak in /etc/cupsd.conf (e.g. it even usually has it’s IP hardcoded in there, so if you change IP address - you have to remember to update that config file).
Same with my Brother printer… been using same printer drivers for at least 10 years.
printer drivers are i386, but scanner drivers are amd64… strange.
I think I prefer my updates one at time. I can see the point with a whole fleet of servers.
CUPS is difficult enough in a single machine.
Did you work out why yum would not update with i686 packages present? It must scan
either the yum database or /usr/lib looking for rogue packages? I have occasional trouble in Debian with an update wiping out the printer drivers, but it does not stop the update. I just reinstall the drivers if that happens.
No - I lumped that into the ‘too hard basket’ and did the “remove ALL 32 bit stuff”… Shotgun blast VS targeted sniper shot…
My Ubuntu (i.e. Ubuntu and PopOS) systems are using the 64 bit driver that seems to be built into the OS - i.e. as mentioned in other posts - I NEVER have to even manually install anything - the system just goes out there, scans my LAN and installs drivers and I never have to lift a finger… More plug and play than anything in Windows or MacOS!
I don’t know how that works, nor do I care, 'cause it just works… Not that I print very often, I vastly prefer the “Paperless Office” concept. And I don’t worry about scanner driver, as I scan direct to FTP on my NAS.
Thats the new printing standard. Its a bit like the old postscript printers, the intelligence is built into the printer, only you dont have to send it a postscript file, you can send it anything…
So CUPS doesnt do much, except spool it.
Confirmed at the regional offices at the top end of West Australia (Kimberley / Pilbara) test prints on Brother printers received after removing, patching, rebooting, re-installation… nearly 3000 km away (Kununurra) - I wish my boss would pay for me to fly up there and verify myself … Broome… yeah - a couple of days in Broome would suit me just fine - but my boss is a tightarse and that will never happen
How many Texas’s is Western Australia ? :
In 30+ years of IT - in many cases with customers or sites across the whole state of Western Australia, I’ve only got remote site travel once - and that was a coal mine in a coal mining town - BORING! And it was a hire car, 3 hour drive, stay in a motel… Ho hum…
Travel is the wrong way.
To appreciate a remote site, go and live and work there for an extended period. It is entirely different to breezing thru on a work trip or a holiday.
