Friday, March 18, 2011

Setting Default Laptop Screen Brightness when Running on Battery Power

A few weeks ago the screen of my "new" laptop (read: my wife's old WinXP laptop) started flickering.

It was almost imperceptible at first, but it got worse over time, to the point that the screen would, at random intervals, suddenly dim gradually and then brighten back, for a second or so.

I suspected that the laptop screen was failing. The prospect of having another headless laptop made me anxious. But after a while I noticed that whenever the screen brightness flickered, a battery icon would show up momentarily in the system tray.

So I came up with a theory: it may be some kind of a power supply problem that causes the laptop, for very brief periods of time, to think that it is disconnected from the mains power, causing it to switch to battery power, which, in turn, causes the OS to lower the screen brightness in order to reduce power consumption.

This theory seemed plausible, but with the warranty long-since expired, and without spare parts (power cord, power supply, battery, motherboard, etc.), my only option was to let it go. After all, other than this issue, the laptop seemed to be as functional as it can be.

The flickering, however, made me crazy, so I searched for a way to prevent Windows from automatically darkening the screen when the laptop is switched to battery power.

Well, it's easy, but it ain't obvious:
  1. disconnect the laptop from the mains power - the screen dims
  2. use the screen brightness controls to brighten the display back to the same brightness level when the mains power is connected
  3. reconnect the mains power
That's it - I kid you not.

A few days ago the laptop switched to battery power and stayed there. I took a little chance and purchased a replacement AC adapter over at eBay. Surprisingly enough, that was it. Happy Happy Joy Joy.

Friday, March 4, 2011

Getting Rid of rkhunter's False Warning about Xzibit Rootkit

I've installed rkhunter a long while ago, mostly because it seemed irresponsible not to install some sort of "protection". But, as is the case with any such tool, I started getting warnings, which, after I got over the induced anxiety attacks, were invariably confirmed as false positives.

It was usually rather simple to silence these warnings from the rkhunter configuration file /etc/rkhunter.conf - most of the time it was just a matter of un-commenting one or more lines, and occasionally updating rkhunter:
rkhunter --propupd
(say, for instance, after upgrading packages).

One false positive that was somewhat more complicated to disable was a warning about the Xzibit Rootkit. This warning is triggered by files containing the string hdparm - it's a known bug (see Debian bug #576680), and the workaround is to "use the RTKT_FILE_WHITELIST option to whitelist initscripts stating this string" - e.g. /etc/init.d/hdparm ...

The comments in the configuration file, suggest that the proper method of whitelisting a file is to also add it to USER_FILEPROP_FILES_DIRS and then update rkhunter. But this makes rkhunter complain that /etc/init.d/hdparm is an executable script, so I had to also add it to SCRIPTWHITELIST.

Bottom line - add the following lines to /etc/rkhunter.conf:
USER_FILEPROP_FILES_DIRS="/etc/init.d/hdparm /etc/init.d/.depend.boot"
SCRIPTWHITELIST=/etc/init.d/hdparm
RTKT_FILE_WHITELIST="/etc/init.d/hdparm /etc/init.d/.depend.boot"
and the run
rkhunter --propupd
Verify by running:
rkhunter --check
I can only hope that I won't hit any false negatives...