Archive for September, 2007

Dead pixel on my new 24″ iMac

Posted by aaron in Apple/os x on September 19th, 2007


I bought a new 24″ iMac last week, and it arrived on Friday. It worked flawlessly for the first day, but on Saturday, I noticed a pixel at the top of the screen about in the middle that was stuck magenta.

A lot of things I was reading said that because the pixel was a color, it was a “stuck” pixel. This would possibly be fixable by one of those programs that flashes different colors really fast.

I ran LCDtest which is a really simple program which just turns the entire screen a color: white, red, green, blue and black each time you press the right arrow. When the entire screen was supposed to be green, there was a black spot, but the spot did not appear in the red or blue screens. This tells me that it is not in fact a stuck pixel, but a dead pixel! And pixels don’t come back from the dead.

After talking to AppleCare on the phone, they pretty much told me that flaws in LCDs are common, and had to be expected, and they would not replace the computer. I was not convinced. I made an appointment with a Mac Genius at my “local” apple store (a two hour drive from my house) and went there this morning. I told him the problem, he took out my computer and turned it on, and then promptly gave me a new one!

So I am a happy camper again!

I bought a firewire hard drive the same size as my iMac’s, and backed up my iMac’s hard drive to it before I took it to the store. When I got my replacement back home, I was able to copy everything back, so I didn’t even have to reinstall my programs! I did this from the terminal (meaning I can make this script run every night to always have a copy of my hard drive at hand) with the “asr” command:

sudo asr restore --noprompt --erase --source /dev/disk0s2 --target /dev/disk1s3

Things to take away:

  • I bought my iMac online, but since I did not customize it at all, I was able to exchange it in the store.
  • Apple Care over the phone does NOT have the last word in the matter. They plainly told me they could not exchange my computer.
  • The pixel was not dead when I took the computer out of the box. It showed up the second day. This means verifying that there are no dead pixels while you are in the store is not necessarily the end of the story.

1 Comment

iptables not logging to syslog

Posted by aaron in Server Software on September 1st, 2007

I was scratching my head on this one for several hours before finally figuring out the solution which turned out to be ridiculously simple.

I wanted to log all incoming tcp connections on port 25 and then drop them. I read through several guides on how to set up logging in iptables. (linuxgurus.com, linuxquestions.org)

Seemed straightforward enough. Here are the rules I ended up with: (output from iptables-save)

-A LOGDROP -p tcp -m limit --limit 2/sec --limit-burst 10 -j LOG --log-level 7 --log-prefix "LOGDROP: "
-A LOGDROP -j REJECT
...
-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 25 -j LOGDROP

Any tcp connections to port 25 should get logged and rejected. You then need to decide what to do with the logged packets, which is where /etc/syslog.conf comes in. You need something like this in /etc/syslog.conf:

kern.=debug     /var/log/firewall

Note that there must be no spaces, only tabs in that line. That line tells any kernel messages that have the “debug” level to be written to the file /var/log/firewall. The –log-prefix 7 part of the iptables rule tells iptables to set the level of the message to “debug”. After changing syslog.conf, you need to restart the syslog daemon, with /etc/init.d/syslog restart:

[root@localhost ~]# /etc/init.d/syslog restart
Shutting down kernel logger:                               [PASSED]
Shutting down system logger:                               [  OK  ]
Starting system logger:                                    [  OK  ]
Starting kernel logger:                                    [PASSED]

I hadn’t seen [PASSED] show up there before, but I didn’t think much of it at the time.

The problem I was having was that there was nothing in the log file. I could see the packets being logged by running dmesg, but nothing went to the file.

I opened up syslog’s startup script, /etc/init.d/syslog, and examined the part where it is supposed to start klogd, the kernel logger. It was commented out, apparently by my vps host. Here is a snippet of my startup script. The bold lines are the ones I added, the commented out ones are what was originally there

start() {
        echo -n $"Starting system logger: "
        daemon syslogd $SYSLOGD_OPTIONS
        RETVAL=$?
        echo
        echo -n $"Starting kernel logger: "
        #passed klogd skipped #daemon klogd $KLOGD_OPTIONS
        <b>daemon klogd $KLOGD_OPTIONS</b>
        echo
        [ $RETVAL -eq 0 ] && touch /var/lock/subsys/syslog
        return $RETVAL
}
stop() {
        echo -n $"Shutting down kernel logger: "
        #passed klogd skipped #killproc klogd
        <b>killproc klogd</b>
        echo
        echo -n $"Shutting down system logger: "
        killproc syslogd
        RETVAL=$?
        echo
        [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/syslog
        return $RETVAL
}

According to some people here, it is not necessary to log kernel messages, and it significantly increases the loadavg. I have already been monitoring my loadavgs on my servers, so I’ll wait a week and see if there is any significant change.

Of course, now that I realize klogd wasn’t even started, this whole thing seems pretty silly.

No Comments