The Boston Diaries

The ongoing saga of a programmer who doesn't live in Boston, nor does he even like Boston, but yet named his weblog/journal “The Boston Diaries.”

Go figure.

Tuesday, June 26, 2007

Sometimes, I wish software were alive, so that I could take the occasional program out back behind the shed to put it out of my misery and maybe scare the rest of the little software programs to behave unless they too, wish to spend the last few seconds of life out behind the shed. What? Me? Bitter?

One of our customers has been having this weird email problem for the past few weeks, and the fact that we're still working on it means that we haven't exactly solved it yet, nor have we (rather, I) found the source of the problem (and the problem? Mail from one of our webservers, S, is being sent to our customer's colocated email server, W. Now, email for W goes through our spam firewall B. So, we have S → B → W. But somewhere along the way, the mail is bouncing back to S with the error “Client host rejected: too many connections( 2 ).” Unfortunately, this is on B, the spam firewall, which is an appliance, which means, we have very little control over its operation, but I digress).

Now, because of that, I've been having to check the logs on various servers, which include the spam firewall. The only way to check the logs on the spam firewall is through a web interface. Said web interface is restricted such that connections from certain IP addresses are allowed, all others rejected. That's fine, except when I'm not at Casa New Jersey. Then, checking the spam filewall logs is rather difficult.

So I figured I would install Firefox on my virtual workstation at The Office. I could then run the browser there (which is allowed access to the spam firewall) and have it displayed on whatever computer I happen to be using (assuming I'm using X Windows). So, on my virtual workstation, I issue the following command: yum install firefox.

Problem number one: I haven't fully thought this through (more on this later). Problem number two (and the more immediate problem at this point): I'm using yum, a package management system. Oh, it installs Firefox all right. But somehow in the process of installing Firefox, yum, for some bizarre reason, decides to delete the contents of /dev.

Now, for those of you who might not be familiar with Unix (of which Linux is a derivative), the contents of /dev are special files that enumerate the devices on the computer. Deleting the contents doesn't actually delete the device drivers (code that manage the devices), but it does make it hard for any programs to find any devices to use. Which leads me to problem number three: my virtual workstation is now useless.

How yum deleted /dev (no—scratch that—I know how yum deleted the files, obviously by using the unlink() system call) why yum deleted /dev/ I don't know. There's no reason why installing Firefox should do that. I resist the urge to debug yum and figure out why it did that, and just accept the inevitable fact that ocassionally, yum will just decide to delete /dev (and possibly other useful stuff like /bin or /home/sean/images/pr0n) and get on with my life (and the problem at hand, which is a dead workstation).

I manage to get my virtual workstation in working condition and now I'm able to log in, and run Firefox.

Oh, that's right—Firefox will check for a locally running instance and tell that one to open up a window, because, you know, sending all that GUI traffic across the network makes it run even slower, even though that's what I want, you stupid piece of XXXX!

Sigh.

And it seems that the latest version of firefox doesn't even support the -no-remote option.

Aaaaarrgggl!

So I go do what I should have done in the first place (problem one)—use an ssh tunnel: ssh -L 8080:spamfirewall:443 virtual-workstation. Then I can point my locally running broswer to http://localhost:8080/ and login to the spam firewall.

Now I can get back to solving the actual issue with email.

Obligatory Picture

An abstract representation of where you're coming from]

Obligatory Contact Info

Obligatory Feeds

Obligatory Links

Obligatory Miscellaneous

Obligatory AI Disclaimer

No AI was used in the making of this site, unless otherwise noted.

You have my permission to link freely to any entry here. Go ahead, I won't bite. I promise.

The dates are the permanent links to that day's entries (or entry, if there is only one entry). The titles are the permanent links to that entry only. The format for the links are simple: Start with the base link for this site: https://boston.conman.org/, then add the date you are interested in, say 2000/08/01, so that would make the final URL:

https://boston.conman.org/2000/08/01

You can also specify the entire month by leaving off the day portion. You can even select an arbitrary portion of time.

You may also note subtle shading of the links and that's intentional: the “closer” the link is (relative to the page) the “brighter” it appears. It's an experiment in using color shading to denote the distance a link is from here. If you don't notice it, don't worry; it's not all that important.

It is assumed that every brand name, slogan, corporate name, symbol, design element, et cetera mentioned in these pages is a protected and/or trademarked entity, the sole property of its owner(s), and acknowledgement of this status is implied.

Copyright © 1999-2024 by Sean Conner. All Rights Reserved.