Tape Backup Doesn't Work!
This is from a newsletter I get called Secure Wire Digest (available at available at http://searchsecurity.techtarget.com/). I've been on about this for years. With the cost of hot-swappable IDE drives and CD media, using tape is asking to get sued for negligence.

CONCERNS RAISED ON TAPE BACKUP METHODS
By Keith Regan
(http://searchsecurity.techtarget.com/originalContent/0,289142,sid14_gci959858,00.html)

Tape drives for consumer-grade systems, as used by most offices these days are very expensive, and they're almost as unreliable as the software that's usually used. The tapes aren't cheap either, as anyone who's bought another case knows.

Tape's reputation as a reasonable way to store data goes back to a time when it was the ONLY way to store computer data. The big drive farms used at real data centers are reasonably reliable, and reasonably efficient.

This article doesn't make it clear whether the study it cites by Meta Group (http://www.metagroup.com/us/displayArticle.do?oid=43441) makes any distinction between the two types of tape systems, but it does point out some of the serious problems, and hints at the very serious consequences of relying on tape.


- posted by Jonathan Hutchins @ 9:22 PM 0 comments

 
KDM Login Problems
It looks like there's a problem using the MIT_MAGIC_COOKIE/PAM authorization system with KDM from KDE 3.2.x. This problem occurs when KDE/X is terminated while a user is logged in, as when there's a power failure or for some reason XWindows crashes. A user logged in through kdm/xdm at the time will be unable to log in again. They can log in to a shell and launch KDE/XWindows with startx, and other users are still able to log in normally.

I haven't tracked this down to it's root cause yet. Clearly, there is some token for the session that's being maintained on the system, and it's not being released, unlocked, reset or whatever when the login is crashed.

Thanks to some help from a "argonel" in #kde on irc.freenode.org, I was able to find a german email that described similar problem, and it's solution.

In file:/usr/X11R6/lib/X11/xdm/xdm-config, the line

DisplayManager._0.authorize: true

is changed to

DisplayManager._0.authorize: false

The "locked" user was then able to log in. We changed the configuration back to "true", logged out, and this aparantly re-set whatever was "stuck", and the user can now log in normally.
- posted by Jonathan Hutchins @ 9:51 PM 0 comments