Brian's Blog

It looks like there's been an update to the Pop-ups Must Die Extension. This one seems to be fine tuned to allow windows that are opened via the target="_blank" part of a URL where the 1.0 version blocked them.

While I haven't personally seen them yet I hear of a rash of pop-ups the somehow get by the Firefox pop-up blocker. Quite a few people at the The Linux Link have mentioned these new pop-ups and Dann pointed out the Pop-ups Must Die Extension which, from what I've read, essentially blocks every new window no matter what it is unless the site is specifically whitelisted.

You just gotta love how fast open source deals with these things.

I think I may have hit a record for the most hits of malicious software on a Windows PC. This system was so slow that it literally took about 10 minutes for me to be able to move the mouse. Ultimately Ad-aware found 2065 hits, Spybot Search & Destroy found 40 or so hits, AVG Anti-virus found 70 or so viruses, and Microsoft Antispyware found another 37 on top of all of that. Also, Cwshredder cleaned off one variant of CoolWebSearch and then I had to finish the clean up with Hijack this.

I don't think I'll ever see another system this bad. I can't believe they were actually using it this way.

After much toil, and with the help of the guys at The Linux Link Techshow I think Bob's system is now stable. In a fit of desperation I checked the jumper settings yet again and got the idea of trying to set memory and CPU manually instead of letting the mobo detect it. It seems that, for some odd reason, the board wasn't detecting the memory correctly and was running it faster than it was intended to run causing all the oddness. I manually set it to 133MHz for PC2100 and it is working fine so far. I tried to talk him into Linux but he wants Windows XP on it. Just getting an OS installed without a freeze is an accomplishment.

When auto-detection works it's great, but when it doesn't it's a pain in the arse. Sometimes I think we should go back to setting jumpers. That way there is no guessing what a board was set at.

My friend Bob gave me his PC to work on a few weeks ago saying it had random BSOD and freezes. Being the friendly neighborhood computer guy I decided to give it shot and get the thing fixed for him. Now, being that I do this for a living you'd think something like this would be easy for me. But this system is by far the worst thing I've ever seen. And at this point, it has me utterly stumped. Here are the current hardware specs:

• Gigabyte GA-7VT600 1394
• 512MB PC2100 Viking Memory
• AMD 3000+ CPU w/ Heat sink & Fan
• 80GB Western Digital IDE Drive (Master)
• 20GB IBM IDE Hard Drive (Slave)
• Sony DVD-RW/CD-RW
• Enermax EG301P-VB Power Supply
• 3.5" Floppy Drive
• Windows XP Pro
• ATI Radeon 9600 w/ 512MB RAM Video Card

I'll try to summarize what I've done below:

Symptoms

The system freezes so often that an install of Windows XP or Linux is unable to finish. When the installs die the problems range from a total lock up which happens in both Linux and Windows to a BSOD in Windows claiming the motherboard is not ACPI compliant which it clearly is. I've flashed the BIOS to the latest version which is F7. It does not consistently freeze or BSOD at any single point. It all seems random. I've also tried other versions of the BIOS including F5 and F6. With F6 none of the drives are detected consistently. All in all, it seems totally random.

Things Tried So Far

I've tried many things so far. So many that I know I won't remember them all. I really should have started a troubleshooting log and taken notes but hey, hindsight is 20/20. Anyway, here is what I can remember at this point, in no particular order.

• Replaced Motherboard and CPU
• Tried each of the hard drives by themselves as master
• Swapped the hard drives so the 20GB was master and the 80 GB was slave
• Replaced the 80GB drive with a new one
• Replaced the power supply with another quality one
• Replaced all cables with new ones (IDE, Floppy)
• Replaced the system RAM
• Rotated the system RAM between all the memory slots
• Tried 3 other different CD-ROM drives
• Tried a different floppy drive
• Tried 2 other different video cards (a GeForce2 GTS and a Radeon 9200)

I've even simplified the system down to the bare essentially of CPU, Motherboard, CD-ROM, Memory, one hard drive, and a video card and yet these symptoms persist. Basically, I've replaced everything but the darn case. At this point I'm absolutely stumped and open to any suggestions from anyone. Thus far I've tried the process of elimination approach to troubleshooting but was thinking if I could run some good diagnostic software it could help me find what the problem is. The problem is I don't really know of any good hardware diagnostic packages that are free and preferably open source.

Feel free to leave a comment. I'm gonna need all the help I can get on this one I think.

I've been tooling around on ##slackware on freenode the past few days and I've noticed a general distrust for automated upgrade tools for Slackware Linux. There are a hand full of such tools but the one that I use is swaret. Two others are slapt-get and slackpkg. Like I said, I only use swaret so I can't say much about the others.

Anyway, while just watching the conversations someone mentioned to just install qt with swaret --install qt in response to a question and another person said something to the effect of "Are you insane?" and went on to say he isn't responsible for the guy hosing his box because "swaret tends to do that". This is far from the first time I've heard such talk and while I understand and respect the policy of ##slackware to not support anything other than the pkgtool I just don't agree with the blanket statement of tools tending to hose systems. The reason I say this is I've been using swaret for several months without a single problem and I think that's not because swaret is the end all be all of tools for slackware but more because I use the tool in a sensible way. In my mind, to blame swaret alone for hosing a system is much like blaming the hammer for breaking your hand when you don't know how to use a hammer in the first place. Just blinding running any upgrade tool without some sane precautions is just asking for trouble, regardless of the tool or the distribution it's being run on.

So, here is how I've used swaret without problems. First, grab at least version 1.7.0test4 of swaret because it supports rollback. Everything from this point on is based on this version, hopefully it won't change much in future versions. Once you download it install using installpkg in the normal way. Then edit /etc/swaret.conf and edit the file to your liking. It's well commented so I won't repeat most of it. Be sure to enable rollback by having ROLLBACK=1 and add EXCLUDE=aaa_elflibs* to the excludes section. Based on the changelog it's a bad idea to ever upgrade aaa_elflibs. One other change I did that isn't 100% needed is to set DSEARCHM=1 so that swaret uses slocate instead of find to search for missing libraries. Just make sure updatedb is run often. Since updatedb is run as a cron job every night by default this shouldn't be a problem. As for the rest of the conf file, just read the commends and go with personal preference for the rest.

That's it for the technical part of it. The rest of how I use swaret is just simply (un)common sense. I run swaret --update followed by swaret --list -u every once in a while to see if anything new is available. If it is I don't upgrade right away. This is where I think most people mess up. First I go read the Slackware Changelog and see if there are any notes regarding the upgrades. Then I do a complete system backup. I have big external USB drive that I use partimage in Knoppix to store a complete image of my system on just before I upgrade anything potentially dangerous like gcc or glibc. If what I'm upgrading isn't terribly dangerous I just backup /etc, /home, /usr/src, and any other data that's important to me. Once I'm backed up and only then do I actually run swaret --upgrade which downloads the updates, backs up the existing installed packages in /var/swaret/rollback, then upgrades the packages using upgradepkg. Swaret just uses the pkgtools (installpkg, removepkg, upgradepkg) to do it's work so it's simply using the standard tools in a script for you. Once its done upgrading I like to reboot and check my dmesg and /var/log/messages for any oddness.

If something is wrong that I can't fix I now have a full system backup and the rollback of swaret to use if needed. Now, I've never had to actually use the rollback feature directly. I've only had 1 or 2 problems that were solved by rolling back an individual package using upgradepkg oldpackagename%newpackagename. As an example, a recent upgrade of udev in slackware-current was bad, so I just rolled back udev like so upgradepkg udev-054-i486-1%udev-050-i486-1.tgz. As I understand it swaret keeps a certain number of upgrades in rollback, I think three by default. From what I've read you would just need to run swaret --rollback # where the # is equal to the number of the rollback you want to revert to. Failing any of this though I have the full disk image from partimage that I can restore my entire system from.

The entire point of this is that swaret and anything else like it is just a tool. Applying a little common sense and taking time to do things right instead of blindly upgrading is all that's needed to make these tools work. To not be careful like this is just asking for trouble.

I've had a ScanJet 3300c that was given to me by a friend sitting on my desk for months. I've been lazy putting off figuring out how to get it to work in linux, mostly because at the time the SANE backend for it was only available as a patch. With the release of SANE-Backends-1.0.15 though it is included. So I figured it was time to stop being lazy. Lucky for me, or so I thought, Slackware 10.1 comes with the SANE-Backends-1.0.15. No matter what though it just flat refused to work on my main system running Slackware-current which, at the moment is essentially 10.1.

I can't fully explain just why it wasn't working, but I can say that on a default fresh install of Slackware 10.1 on an older extra system the scanner worked fine. After much Googling with not much of use I found a few hits saying that the scanner sometimes has trouble with USB 2.0 since it was one of the first USB scanners released and was designed for USB 1.1. This didn't make sense to me because it worked fine on Windows XP with the exact same hardware but I grabbed a USB 1.1 PCI card and gave it a shot, which didn't work.

I ultimately got frustrated and downloaded the source for the SANE-Backends and compiled it myself. Surprisingly it actually worked. It doesn't make any sense to me since the same binary package in Slack 10.1 worked on another system but not on this one. Apparently I changed something along the way on this system to make SANE unhappy with this scanner. I'm guessing maybe a library somewhere along the way that a compile corrected. Either way, the scanner works and I'm happy.

It's been a while since I figured out something new to me on Linux and it's been kind of bothering me. So I decided to take a crack at udev. I'm running Slackware-current, which at the moment is essentially Slackware 10.1 plus an updated x.org. I figure by now most other Linux distro's are already using it, but since Slackware favors stability over the latest and the greatest we still are on traditional /dev files. But, rumor on the street is that Slack 10.1 is the last to use the 2.4.x kernel and that Slack 11 will use 2.6.x by default. So it stands to reason that it will also use udev since udev requires Linux kernel 2.6.x. Slackware 10.1 comes with a precompiled 2.6.10 kernel in /testing on CD 2 but since I've been using 2.6.10 for a bit already I just grabbed the udev packages with swaret. But for some reason my home grown kernel caused udev to act strange. Strange as in su would not work, and I couldn't open up an aterm or xterm. Also, for some reason, my cdrom just would not be detected by udev. All these odd things and everything worked 100% before trying udev out. As far as I could tell all you need for udev to run is hotplug and sysfs which I already had in there. So, just to make sure, I grabbed the config file from the stock Slack 2.6.10 kernel and compiled to that which got everything working. So, all my woes came down to me missing something in the kernel. I'm not sure what yet and I'm not sure if I'll ever figure it out, but the point for the moment is to learn something about udev.

Oh, the default 2.6.10 kernel in Slackware has reiserfs as a module. I'm glad I saw this and compiled it into the kernel or I would not have been able to boot since I use reiserfs for my root file system. There is a readme in the /testing/packages/linux-2.6.10 directory about using initrd to overcome this but it seems more complex than just compiling reiserfs right in.

Anyway, so after that everything seems to work correctly but in a standard way. Except for my external USB hard drive, which for some reason wanted to be called /dev/uba instead of /dev/sda. After a bit of googling I found that this is because of something called "Low Performance USB Block driver" in the kernel which claims to cripple the usb-storage driver when enabled. This sounded silly so I disabled it and now my drive is back to /dev/sda. I'm not sure why this was even enabled in the first place but I'm sure there is some reason. At this point then I wanted to learn more about udev rules. It turns out all I really needed was this article, which covers creating consistent names for things that can change, like USB drives, or systems with multiple printers and udev rules in general. Makes rules wasn't as hard as I though.

One thing though that seems to be not covered much is changing permissions. You can chmod a device but it will revert to it's default permission on reboot. I wanted to change my dvd-rw on /dev/hdc to allow writing. So I took a look at the file udev.permissions in /etc/udev/permissions.d and saw this section:

# disk devices
hd*:root:disk:660
sd*:root:disk:660
dasd*:root:disk:660
ataraid*:root:disk:660
loop*:root:disk:660
md*:root:disk:660
ide/*/*/*/*/*:root:disk:660
discs/*/*:root:disk:660
loop/*:root:disk:660
md/*:root:disk:660

I thought this was exactly what I needed and added a line to it to make it look like this:

# disk devices
hd*:root:disk:660
hdc:root:cdrom:666
sd*:root:disk:660
dasd*:root:disk:660
ataraid*:root:disk:660
loop*:root:disk:660
md*:root:disk:660
ide/*/*/*/*/*:root:disk:660
discs/*/*:root:disk:660
loop/*:root:disk:660
md/*:root:disk:660

Even so it flat refused to change /dev/hdc to mode 666. Linuxquestions.org and Google weren't much help. But then I took a look at udev.rules in /etc/udev/rules.d and saw this line at the top:

BUS="ide", KERNEL="*[!0-9]", PROGRAM="/bin/cat /proc/ide/%k/media", RESULT="cdrom*", NAME="%k", GROUP="cdrom", MODE="0660"

What struck me was the MODE="0660" part. So I changed it to read MODE="0666" and the permissions change as I wanted on the next reboot. I haven't found it documented anywhere yet but it seems that a MODE setting in the udev.rules file takes precedence over anything in the udev.permissions file. I took some time to plug in and move around my USB drives to see how it handles it and it worked well, keeping all the symlinks I created in my custom rules pointing to the correct device regardless of what it was. Now my /dev directory is small enough to fit on one screen vs scrolling many screens.

I really didn't need to get udev up an running, but now that I see it in action it's nice. I think I'll keep it.

The past couple of weeks have been "interesting". Interesting in that I've spent so much time shaking my head in disbelief. I've mentioned that I think my work has been reduced to cleaning Viruses and Spyware from Windows PC's. I think that's true to some degree but these idiots who keep bringing in their PC's without any Antivirus software on it for me to fix are driving me insane. I mean, if you choose to run that giant petri dish that Microsoft passes off for an OS and not run Antivirus you are just asking for it. To me its kind of like spending a week at a brothel without a box of condoms, then wondering why it burns when you pee. Really, there is no excuse. Especially when you can grab Norton Antivirus 2005 for something like $50 or download AVG from Grisoft which is free for home use. Today was a particularly bad one. I had to disinfect a PC and found 6318 instances of just Netsky. Then, I was asked, "Is it bad to not have Antivirus"? Then there was spyware on top of that too. Sometimes I wonder why people don't show more interest in Linux or Mac.

I made an attempt to learn something about udev last night. I'm running Slackware Linux 10.1 which doesn't have udev by default yet. My 2.6.10 kernel is home grown and should be setup correctly so I grabbed the udev slackpack with swaret. I didn't even get as far as learning the rules or setting custom permissions because, for some reason, it just decided to not see my DVD/CD-RW which is on hdc. There was also other very odd weirdness that I can't explain, such as su stopped working, and I couldn't open an xterm or aterm. I'm guessing it's because the tty devices weren't setup right. Which tells me I'm missing something in my home grown kernel. Perhaps I'll just use the stock 2.6.10 kernel which should hopefully work. I can't say I really need udev since things work 100% on my system now, but I'd like to at least know something about it.

Not that I need any more computer books, but I decided to order up a copy of Knoppix Hacks which looks like a good book and has gotten killer reviews on Amazon. I took a look at the table of contents at Borders this weekend and it looks chock full of ways to use Knoppix to bail out Windows. Which is my primary use of Knoppix anyway. Maybe one of these days I'll actually read a novel or something instead of a technical manual.

Jhigdon on the LVLUG mailing list sent a link on how to install Linux on a Mac Mini. I'd go grab one of these and try it out but money is a little tight these days. Time to start saving I guess.

Since I'm stuck running Windows on my laptop for work I decided to at least make it look like I was running a sensible OS. A few years ago I bought a program called Altdesk that add desktop switching to Windows. It only took M$ till XP at that, and only as a powertoy and a crappy powertoy at that. Even so Altdesk is better. Altdesk is actually a companion program for a substitute shell for Windows called Astonshell. Anyway, since I had bought both Aston and Altdesk as a package deal and never used Aston I took a hunk of time out of my work day to fiddle with it and take a screen shot.

It's nice not having to look at the same old, same old. The plugin's are nice, but few. Though it looks like it could be very configurable if you wanted to make your own skins. It's no windowmaker, but it's better than the stock shell in Windows and seems to be a tad faster.

I also just heard about Blackbox for Windows today which I may check out if the spirit moves me in the future. For now I have my different looking desktop and can fantasize about running Linux at work.

As a total side note, the boss blindsided me today. I over heard him actually suggesting to one of our residential customers to not use Internet Explorer and try out Firefox! I had the pleasure of "disabling" IE on this guys laptop and installing Firefox. It looks like a little bit of my preaching is finally sinking in.

I've been reading Mastering Microsoft Exchange Server 2003 off and on for quite a long while. I can say that learning Exchange hasn't been high on the priority list but I'd been instructed to learn something about it for work so Brian went and learned about it for work.

Anyway, I have to say that I wasn't terribly impressed with this book. It does cover everything you would ever need to know and then some. But it seems to cover it in to much detail. Detail normally isn't a bad thing, but the kind of detail that it seems to center on are basic things that anyone who has worked with Windows long enough to consider setting up an Exchange Server would already know in their sleep anyway. For instance, it goes into a great explanation on how to manage services under Windows 2000/XP. Why do we need that kind of into in a book about Exchange? Additionally, it tells you all you need to know to setup a POP3 account from the point of view of a complete mail newbie. Let's consider that if someone doesn't know how to setup POP3 on the client that they probably shouldn't be setting up a mail server of any sort.

I could probably go on and on with these kinds of examples. I'd be willing to bet that the book could be cut in half if the extra unneeded "this is how you use Windows" stuff were removed. Don't get me wrong, the material on Exchange itself is informative, but the long explanations of basic Windows administration put me to sleep.

I'd say this would be a OK reference book if I ever need to actually apply it at work, but I think I should have looked around for a better book on Exchange. At least I can finally shelf this one and move on to reading something else. Perhaps a good book on qmail.

A Public Service Announcement regarding the crisis that is known as Service Support Termination Trauma (SSTT) can be found here.

Please, don't let SSTT happen to you.

I just wrote up a quick article on how I managed to change from Windows to Linux successfully and put it in the articles section here. I know, just what the world needs is yet another one of these but I just couldn't resist.

Just for giggles here's a screen shot of me writing it using vim and jamming to some tunes in xmms.

I've been working with Linux for a relatively short time, I'd say between 1.5 to 2 years total. In that time I've learned many things but one thing that has always scared me is Regular Expressions. Most of the books I've read so far in my Linux adventures have only touched on the subject not really going into any practical depth. I did take a brief look at Mastering Regular Expressions but it's way over the top for my purposes. The problem is or was that I just could not find a book that was somewhere in between these two extremes.

On a whim while killing time at Borders I bought Sams Teach Yourself Regular Expressions in 10 Minutes. And you know what? I'm glad I did. This book claims to be the middle ground that I was looking for and it does it by practical example. Each subject section begins with a brief explanation of the concepts and syntax then goes on to demonstrate the concept with examples and easy to understand explanations. The explanations even break down the expressions into smaller easier to swallow chunks. Some of them even show you what you would come up with off the top of your head, then go on to demonstrate how that expression would fail and end by explaining how to improve the expression.

The one feature that I feel will make the book a good reference for me is the cheat sheet on the inside back cover. It gives a list of all the syntax broken down into categories such as Backreferences and Lookaround along with a short description and the lesson that it was covered in. Also, the lessons are short but complete for my purposes with each one taking 10 minutes or so to complete on average. This way I could go back and reread an entire lesson if I needed and not have to slug through page after page of text to find what I want. Also Appendix B contains a list of extra examples showing how to solve common problems such as matching phone numbers, credit card numbers, IP addresses and URLs.

The only negatives that I ran into were a couple of obvious typos and a few examples that did not want to work with the downloadable regex tester. As far as the typos go they were so obviously wrong that I could tell what was really meant by the context clues. And I'm not 100% sure that the few examples that didn't work were because of a flaw in the regex tester or my system. Either way though they were not bad enough to hinder my ability to learn what was being discussed.

To give better idea of what is covered here is the table of contents:

1. Introducing Regular Expressions
2. Matching Single Characters
3. Matching Sets of Characters
4. Using Metacharacters
5. Repeating Matches
6. Position Matching
7. Using Subexpressions
8. Using Backreferences
9. Looking Ahead and Behind
10. Embedding Conditions

Sam's Teach Yourself Regular Expressions in 10 Minutes does not claim to be a complete coverage of everything regular expressions. It does claim to be a guide to help you get up and running fast with regex and it does just that in my opinion. I can't wait till I run into something that lets me use my new found skills.