(Grab an old sponge - yes, seriously)
I have a Canon Pixma MG5750, a Currys PC World purchase when I needed a cheap multifunction printer fast. Handy at £45 (another set of genuine ink for it costs the same, go figure). I never expected it to be perfect, I assumed it would at least be able to reliably accomplish basic things like print text onto paper.
Unfortunately, one of the fundamental printer requirements - loading its own paper during print jobs - was a little lacking with this unit. Research indicates it's sadly a common issue with this range of Canon printers.
Soon after buying mine, the paper feed (take-up of paper from the tray into the transport mechanism) started to behave irregularly. Soon after that, I ended up having to nudge each sheet of paper in to the printer, it was unable to take in paper itself. Not convenient.
I put up with this for a while but an attempt to print some documents evening pushed me into investigating. The fix, as it turns out, is really simple!
Click to read more and see photos of the paper feed roller fix
I noticed recently that a few web sites are miscategorising my ISP's static IP as being in the wrong country. I knew it was a recent reallocation of a new block and suspected the web sites were using a stale version of a GeoIP database - probably MaxMind's GeoLite v1 offering.
If you see stuff like this while surfing the web, your IP is probably in the same boat:
It's such a stupid problem, but it's all due to lazy server admins or designers
I recently had to diagnose a couple of servers running Postfix which emailed results of rsync cronjobs when they returned a non-OK value. While Postfix was emailing the recipients on rsync failure, I noticed that the cronjob STDOUT was not being locally relayed correctly to the root mail.
I documented my fix on ServerFault, hopefully it's useful for someone else.
Having fixed local root cron reports, I then noticed on the CentOS7 box that the AIDE service was running, had been scanning for integrity checks against the original postfix install (subsequently upgraded to Postfix 3) and as such was throwing errors every night for no real reason, quite annoying.
To fix this I tried running
aide --update but it didn't work (probably my fault from doing an
--init first). I had to rm the
/var/lib/aide/aide.db.new.gz files, then
run aide --init and rename the newly-made
aide.db.gz. After that, it was happy.
I've been working with Oracle Session Border Controllers and Enterprise Communications Brokers a lot recently, A couple of weeks ago I encountered what I think is a new - and quite serious - bug (it's with Oracle for investigation) regarding how the devices *mis*handle special characters. If you admin ECBs or SBCs and are planning to change their credentials to include non-alphanumeric characters, read this first.
I've been working with Oracle Session Border Controllers and Enterprise Communications Brokers a lot recently, and I encountered what I think is a new bug (it's with Oracle for investigation).
After deploying some new ECB instances, I changed the login and enable passwords, per the Oracle ACLI guide ("secret login" and "secret enable" at the SSH prompt). I used randomly generated strong passwords which included limited special characters -- "#", "%", "?" and "!".
The ECB appliances use two passwords per username - one to log on to the unit, and one to 'enable' (admin mode for configuring them, similar to Cisco's enable mode).
On one appliance, the new password I generated for it was accepted without complaint when typed and retyped at the confirmation prompt. However, attempting to then authenticate a new session using this password resulted in immediate refusal by the appliance. It effectively denied access, with no recovery method. I had to flatten and redeploy the appliance! Continue reading "Tiplet: DO NOT USE the # symbol in Oracle Enterprise Communication Broker passwords!"