Printers, manuals, paper jams and… users

And now to something completely different 🙂 I’ve had an ongoing, low priority, personal support effort for some days, where a printer started printing highly distorted results.

Brother MFC-5895CW: sample of corrupted print-out

I knew that the printer was rather new and not really stressed, I even trust the manufacturer to delivery quality and the printer model in question (Brother MFC-5895CW)  wasn’t from the lowest-end consumer spectrum. All in all: I’d have suspected that printer to last longer than 3 months without causing severe problems.

As this was a “remote support situation” (I had only contact via phone and couldn’t put my hands on the machine) all I had were the user’s descriptions and a scan of a affected print-out (see the sample). The printer manual nor the FAQs gave an obvious hint to the user, and having looked at the sample, my first idea was a mechanical defect. But after some exchanges the user gave the finally helpful piece of information: While handling a rather resistent paper jam, the user had to pull out the paper by opening the top cover and reaching inside. There, was the report, had been “a white strip with a message not to touch it”, but the message was only noticed after dragging out the paper.

Scanning through the online FAQs for paper jams that “do not touch” message was mentioned again… it’s not about the “white strip”, but about an “encoder strip”: “DO NOT touch the encoder strip. The encoder strip is a clear plastic strip in front of the white vinyl band ([…]). If the encoder gets markings or debris on its surface, it may cause other problems.”

For sure, there were marks on the strip, most probably finger prints from the paper jam resolution efforts.

Why this blog about something that trivial? Well, because despite the easily to create situation of soiling that strip, there’s only hard-to-find information on how to clean it properly (as a matter of of fact I only found that article when searching the web while writing this article). Something like “Distorted print-outs after having opened the top cover? Check the encoder strip!” would have been really helpful in saving some time and efforts. And as that user told me when confirming that cleaning the strip did the job:

“Why, when they know this might happen, don’t they put that information in the manual, rather than hiding it online?”

(Dear Brother documentation team, if you read this, please note that the user did *not* receive messages about persisting paper jams… the printer did print the jobs, but simply unreadable.)

By the way, the printer is still rated positively, except for it being rather talkative (a way to reduce the beeps would be welcomed). It’s doing its work quite nicely, being used from a WLAN-connected Linux machine via CUPS & SANE and using the Brother-provided drivers. The setup was easily done following the instructions – all in all, a fine piece of hard- and software. And I can second that user’s opinion, having used Brother equipment for many year in Linux environments.

Posted in Uncategorized | Tagged | Leave a comment

Adobe’s time-bombed software

I usually tell people we’re a Linux shop – but no rule without exception: We actually have two “Microsoft Windows”-driven PCs, and one of those two is used for a bunch of Adobe tools.

As part of a hardware upgrade, we decided to completely reinstall the software on that machine… it had been running fine for years, but especially the disk drive was getting old and started to make some noise. (Installing Windows XP on an SATA machine is worth its own blog entry. OTOH, there are plenty of sites describing both cause and solution, I’ll probably skip that.)

In the end, after dusting off our “Adobe CS3 Master Collection” media and some hours of time, installing CS3 wasn’t much of a hassle. Which simply means that we seem to know our way around the stones and pebbles that are in the way. But this time, something new popped up afterwards: Running the post-installation updater cycle would only lead to some error messages rather than install latest code levels.

Searching the net provided the solution, again. It did take some time to find it, but others indeed had run into this as well: The Adobe CS3 software is a bit “oldish” now and the certificates included with the updater application have expired. The work-around is simple, just turn back the system time to some pre-expiration value (any date before October 17 2011 will do) and there’s even a knowledge base article available from Adobe. But what I will simply not understand: Why does Adobe have to be so user-unfriendly as not to provide a patch for the updater, installing new certificates? After all, customers have spent a serious 4-digit amount of money to buy that software, so I expect to be able to install and update it not only two years after purchase, but for as long as I can come up with a base system meeting all technical requirements! Especially since the various updates are still online at Adobe, it’s just the updater that cannot verify the signatures.

The only way to top this would be to turn off the license key servers. And from what I’ve learned about Adobe and their user-friendlyness in the past years, I wouldn’t be surprised if they’d do exactly that. Just to force people into buying the latest CSx levels.

I wish we had some (Linux) tool chains that would do the job… ’til then, we’ll have to stick with Adobe 🙁

Posted in Uncategorized | Leave a comment

Horde4 to Kolab 2.2

Being an all open source company with a team spread across cities, e-mail and chat isn’t all we need – some groupware is in order. With our close relationship to customers from the public sector, Kolab was on top of our list. So we created our own installation of a Kolab 2.2 server a few years ago.

With its monolithic structure (Kolab was designed to run its own versions of the various components like Postfix, Cyrus IMAP, openLDAP and so on) the installer was (and is) designed with an all-on-a-single-host approach in mind.

One of the included components (although from a separate project) is Horde, the open-source webmail client framework.Our first attempt to create a separate install on a web server outside the internal network seemed promising, but was substituted by a mail-only client (SquirrelMail) due to increasing performance problems. Another attempt with a new Horde release (v1.2.9) was usable, but we didn’t find the time to submerge far enough to get the Kolab integration add-on configured.

After a few years and an increase in team size and requirements towards groupware functionality, I drew the short straw a few weeks ago and started a new attempt at installing Horde: This time version 4, this time with Kolab integration right “on board”.

For the better part of a month I’ve been trying to get Horde4 up & running and I must say, this is not the way I’d like it to be. (I’ve since had been in contact with the developer – the integration is not yet finished – what I’m facing are still beta code problems. Watch out for version 4.1, which is the current target version for a working Kolab integration!)

To sum up all those hours and late nights: Horde4 does need PHP 5.3 (unlike the test page suggests) and once you start using Kolab back-ends, you’d better get the configuration right or you’ll be fighting PHP errors to no end.

Unfortunately, the web-only configuration interface is not ready in Horde4, so in addition to the parts you can do there you’ll need to configure some back-ends, too. But there’s light at the end of the tunnel: For the final code, there’s a special Horde4/Kolab-webmail bundle planned, which will make standard integration much easier.

Just for reference, here’s the list of essential config changes in the main Horde4 config file (config/conf.php from you installation root) as we’ve deducted from our tests:

// $conf[‘auth’][‘params’][‘app’] = ‘imp’;
// $conf[‘auth’][‘driver’] = ‘application’;
$conf[‘auth’][‘driver’] = ‘kolab’;

// $conf[‘prefs’][‘params’][‘driverconfig’] = ‘horde’;
// $conf[‘prefs’][‘driver’] = ‘Sql’;
$conf[‘prefs’][‘driver’] = ‘KolabImap’;

// $conf[‘datatree’][‘driver’] = ‘null’;
$conf[‘datatree’][‘params’][‘driverconfig’] = ‘horde’;
$conf[‘datatree’][‘driver’] = ‘sql’;

// $conf[‘share’][‘driver’] = ‘Sqlng’;
$conf[‘share’][‘driver’] = ‘Kolab’;

// $conf[‘accounts’][‘driver’] = ‘null’;
$conf[‘accounts’][‘params’][‘attr’] = ‘uid’;
$conf[‘accounts’][‘params’][‘strip’] = true;
$conf[‘accounts’][‘driver’] = ‘kolab’;

// $conf[‘kolab’][‘enabled’] = false;
$conf[‘kolab’][‘ldap’][‘server’] = ‘ldapserver.ourdomain.com’;
$conf[‘kolab’][‘ldap’][‘port’] = 389;
$conf[‘kolab’][‘ldap’][‘basedn’] = ‘dc=ourdomain,dc=com’;
$conf[‘kolab’][‘ldap’][‘phpdn’] = ‘someneatdn’;
$conf[‘kolab’][‘ldap’][‘phppw’] = ‘someneatpassword’;
$conf[‘kolab’][‘imap’][‘server’] = ‘imapserver.ourdomain.com’;
$conf[‘kolab’][‘imap’][‘port’] = 143;
$conf[‘kolab’][‘imap’][‘sieveport’] = 2000;
$conf[‘kolab’][‘imap’][‘maildomain’] = ‘ourdomain.com’;
$conf[‘kolab’][‘imap’][‘cache_folders’] = false;
$conf[‘kolab’][‘smtp’][‘server’] = ‘smtpserver.ourdomain.com’;
$conf[‘kolab’][‘smtp’][‘port’] = 25;
$conf[‘kolab’][‘freebusy’][‘server’] = ‘https://kolabserver.ourdomain.com/freebusy’;
$conf[‘kolab’][‘enabled’] = true;

Please note that we use different LDAP- and SMTP servers (than simply the Kolab server) at the location where the Horde4 is served. There’s some preliminary config stuff for the later Kolab-integrated bundle which assumes all is on a single server – go have a look, especially at the configured backends, which you will need on top of the changes above. We’ve set up backends for IMP, Ingo and Turba, Ingo was changed to employ the Kolab driver, as was Turba.

What do you get after all this setup work? We still see many problems that we’re trying to work out, both on our own and with the help of the Horde developers. Webmail works, but for us, neither calendar nor address book nor to-do list integration does. Sometimes not even for a users’ own files – and shared resources are definitely a problem. It all may boil down to some trouble with IMAP server access, we’re seeing many error messages when annotations are to be set, but it may be a bunch of different problems and missing functionality as well. YMMV.

 

Posted in Horde, Kolab | Leave a comment