It’s only the check printer, no big deal

From our friends at The Daily WTF:

There was nothing unusual about an unusual ticket. Matt worked helpdesk at an assembly plant, and not a week went by without some confusing brain-bender from his users. He didn’t blink when he received this ticket:

We’re having an issue with our check-printer. Every time a user logs on, it prints out an inventory of electrical parts dated from 1984. On our checks. This is causing some accounting issues.

The ticket provided plenty of other details. Matt called the user and ran through the standard questions and answers. No, it wasn’t specific to any particular user. No, there was no job stuck in the local queue. Yes, it really was printing out an inventory from 1984, and yes, all over their checks, and no, those checks couldn’t be used after that.

Thinking it might be an issue with the printer’s memory, Matt checked on the printer itself. It was an ancient dot-matrix printer with about as much memory as a goldfish. It couldn’t remember its last job, let alone a zombie job from 1984. He also checked the computer’s network settings, and noticed something unusual.

“Why is this computer in the DMZ? Does it need a public IP?”

The user had no idea, but Matt’s co-workers did. This computer printed out accounting data based on information that existed in the central mainframe back at the corporate headquarters. It was one of the few computers at the facility that could access the mainframe directly. In order to “secure” the mainframe from external attackers, it was programmed to only accept inbound connections from certain, specially blessed, IP addresses.

A little lightbulb flickered to life in Matt’s head. If the computer could open connections to the mainframe, it stood to reason the mainframe might be able to talk to the computer. The mainframe had data stretching back to the time of Caesar Augustus, let alone 1984. He tested his theory by sniffing the packets that arrived at the computer. Sure enough, every time someone logged in, a bunch of packets came from the mainframe, kicking off the print job.

Matt passed the ticket along to the mainframe team, figuring they could take it the rest of the way. It came back a short time later.

Program SC24P is working as designed. The reason print-jobs are only arriving when a user logs in is probably related to some inability of Windows to receive print-jobs without a user present. Close this ticket.

Matt sent his own reply back, explaining that the issue wasn’t the jobs not coming in. It was that the same job came in every time a user logged in.

Program SC24P is set to retry failed jobs. This behavior is by design. Close this ticket.

Matt tried again, explaining that this computer shouldn’t be receiving any jobs at all, retries or otherwise.

Program SC24P is set to use IP 74.50.110.120 as a secondary printer, in case the primary printer fails. This is by design. If you don’t want this computer to receive these jobs, you’ll need to file a change request. At a high-level, it’s roughly 10–20 days, possibly more. These IP addresses are hard-coded into our custom print-queue manager. And before you ask, no, our custom print-queue manager doesn’t have any functionality for removing a job from the queue. The only way to clear the queue is to reboot the mainframe.

If the mainframe team couldn’t change the IPs they print to, maybe Matt could change the IP the computer used. Unfortunately, whatever IP he used needed to either be in or be added to the mainframe’s whitelist. It didn’t take long for the mainframe team to estimate figuring that out as a 10–20 day effort. Matt went back to the user with the bad news.

Oh, that’s no problem. We fixed it on our end. I hung instructions next to the computer. Before anybody logs on, they need to unplug the printer, wait five minutes, and then plug it back in.
You can close this ticket, thanks!

via: [The Daily WTF]

Picture Source: [brianholcomb (CC)]

[fixed] Your dad asks iPhone Questions

I don’t know how or why I did not know about this series of videos until recently, but you will see a lot more of them in the coming weeks.  Good stuff, even if it has been around for a few years!

My favorite line here – - “Don’t turn it on – IT WILL WASTE THE BATTERY!”

via: [Current TV @ YouTube]

- This was originally posted on the 27th but was missing the video! Apparently in my post-pneumonia stupor, I’m not verifying my posts correctly. Sorry everyone, it is now fixed! – Rob

Tech Support: 1800′s style

This one’s a tall image, scroll to the bottom for the transcript:

tech support in the 1800'sTranscript via ohnorobot.com:

“Dear South Asian Techinical Support Corporation. / I have recently purchased one of your Analytical Engines and my cycle apparatus is consistently off by unity. / Please advise. / Sincerely, / Lord Bradenham, Esq.”

“Dear Lord Bradenham. / This is Vidhur. Hello. Did you remember to have your man-servant crank the mill of the Analytical Engine? / Yours, / Vidhur”

“Dear Vidhur, / Indeed. / Sincerely, / Lord Bradenham, Esq.”

“Dear Lord Bradenham. / Please have your man-servant cease cranking the mill, then commence cranking once again. / Yours, / Vidhur”

“Dear Vidhur, / Having done so, the problem persists. / Sincerely, / Lord Bradenham, Esq.”

“Dear Lord Bradenham. / Please hold off on your missives whilst I communicate with my supervisor. / Yours, / Vidhur”

“Dear Vidhur, / Very well. / Sincerely, / Lord Bradenham, Esq.”

“Dear Vidhur, / I have been on hold now for three and twenty weeks. I wrote you during Winter, and had intended to travel to Austria-Hungary come spring. This plan shall now be postponed, despite your corporation’s guarantee of technical redress within fourteen weeks of postmark. / Sincerely, / Lord Bradenham, Esq.”

“Dear Lord Bradenham, / This is Rajdeep, Superintendent of South Asian Technical Redress corporation. / Did you remember to have your man-servant crank the mill of the Analytical Engine? / Yours, / Rajdeep”

“Dear Superintendent Rajdeep, / Having done same with your inferior, Vidhur, I respectfully request you consider this problem more seriously. I have been seeking Technical Redress for nine and twenty weeks now. / Sincerely, / Lord Bradenham, Esq.”

“Dear Lord Bradenham, / My apologies for the difficulty. Please have your man-servant cease cranking the mill, then commence cranking once again. / Yours, / Rajdeep”

“Dear Superintendent Rajdeep, / Indeed I have, and the problem persists. / Sincerely, / Lord Bradenham, Esq.”

“Dear Lord Bradenham, / I must consult sundry technical manuals. Please enjoy the enclosed music box whilst I attempt to determine the problem. / Yours, / Rajdeep”

“Dear Superintendent Rajdeep, / It has been nine and thirty weeks, and I am unsatisfied with your technical redress. Your service is sub-felicitous and your music box plays only that music which was created prior to the 1860s. / Sincerely, / Lord Bradenham, Esq.”

“Dear Lord Bradenham, / Our apologies for the significant wait. We have determined that the cycling crank on your Analytical Engine is too long, resulting in overly fast cycles. We recommend you either purchase a shorter cycling crank or hire a man-servant with weaker arms. / Yours, / Rajdeep”

“Dear Superintendent Rajdeep, / Very well. / Please send me a shorter crank free of charge. / Sincerely, / Lord Bradenham, Esq.”

“Dear Rajdeep or Vidhur, / Have you received the recent several messages I have sent? It is not three and sixty weeks since I first wrote, and your technical redress remains unsatisfactory. / Please reply post-haste! / Sincerely, / Lord Bradenham, Esq.”

“Dear Lord Bradenham, / The technical file for your case was inadvertently lost in the War against the Damnable Burmese. / Please re-inititate communication. / Yours, / South Asian Technical Support Corporation”

“Dear South Asian Technical Support Corporation, / Please make a priority of repairing my defective Analytical Engine! / Sincerely, / Lord Bradenham, Esq.”

“Dear Lord Bradenham. / This is Vidhur. Hello. Did you remember to have your man-servant crank the mill of the Analytical Engine? / Yours, / Vidhur”

The Sunday Times newspaper headline reads, “93 British Lords Go Mad In Same Month. Cause Unknown.” Another article headline reads, “Indian Rebellion Looms.”

via: [Saturday Morning Breakfast Cereal]

 

 

Security fail #2: badge problems solved the old fashioned way

Back at my old job, we had a “Configuration Center.” It was an area that was dedicated to unboxing and building/deploying new desktops and laptops for an agricultural/construction equipment manufacturer.  When a good portion of the downstairs area was remodeled, our entryway got a magnetized security door which was opened by our access badge on the outside and a via a metal panel on the inside which was activated by touch capacitance.

One day after the remodel, everyone else was either out to lunch or deploying computers and I had to get in ASAP – and of course, I forgot my badge inside.

The doors were secure enough, but there was a gap on the hinged side.  Seeing this, I grabbed a wire hanger from a nearby office, bent it at an angle and slid through the opening by the hinges…I then turned it and tapped the panel – then heard a satisfying *click* as the door unlocked.  I had to do this a number of times (yeah, I’m forgetful) during my tenure there.

The sad thing is that door was monitored via camera by the on-site security group, and they were right down the hall (like 30 feet) from us.  Did we ever get questioned as to why we were getting in the room that way?  Nope – far as I know, the door is still set up that way.

Picture Source [Elsie esq. (CC)]