Just a heads-up, gang. As previously mentioned, it looks like the blog is going to be moving. I’ve finally received the official go-ahead from the powers that be at Keenspot that they’re okay with the move. I’m not sure yet when it will officially happen, but seeing as I’ll be on a business trip next week, it might be a week or two. I’ll have to iron out the details with the Keen Tech Crew first.
So what does this mean for you? Well, if you read this blog via a Web browser, probably nothing. Just keep using the old www.jeffdarlington.com domain name and you shouldn’t notice any difference, just that one day the blog won’t have Keenspot ads and the next day it will. Isn’t the magic of DNS grand? (If the ads bother you, then I’ll go ahead and make the prerequisite plug for Keenspot PREMIUM, which removes those ads and puts a few extra bucks in my pocket at the same time.)
If you’re checking for updates via one of the XML feeds like RSS or Atom, you might want to periodically peek in via a browser, especially if I seem even more silent than usual. (Yeah, I know, that’ll be hard to notice as my updates are somewhat sporadic. Sorry about that.) The reason I mention this is that the feed links currently bypass the dynamic DNS’ Web forwarding (i.e. the translation from the domain name on port 80 to the IP on the real port; check this post for the gory details). Unfortunately, when the site moves to Keen, that alternate port will no longer be available and the XML feed links will return back to port 80. To anyone currently using the feeds on the alternate port, the feed will appear to break. You’ll need to keep an eye on the feed URLs to notice when they update. I’ll look into ways to redirect them, but I doubt Keenspot will be willing to jump through those hoops just for me.
If you don’t read this blog, then… well… what are you doing here, then?
I’ll try and keep you apprised of things as often as I can. I plan to move as much data from one site to the other as possible, so hopefully those of you who have already signed up for commenting shouldn’t need to worry about signing up again. Thanks in advance for your patience.
Not a good blog weekend. But now the weekend is over, and everything looks to be back in working order. For the moment. I hope.
Comments should now work, I believe. Tim from Germany came to our rescue again and pointed me toward a WordPress plugin called wpPHPMailer. This wraps the more generic PHPMailer script into a WP plugin and allows WP to send mail via a third-party SMTP server instead of through PHP’s mail() function, which uses the server’s built-in mailer (like sendmail). Thus, I can get around the problem of WP sending out password confirmation e-mails and commenters should be able to register. You’ll find the registration link in the Meta part of the side bar (right above the “brain dump truck” image).
As for why the blog was down all weekend… blame my ISP. Sometime Saturday, our power flickered. The computers were fine, as the laptops went on battery power and the desktops flipped to the UPS. However, something must have happened between the ISP’s router and our cable modem to cause them to “lose” our cable modem’s MAC address. Yeah, I don’t understand that one either. The ISP and the cable modem wouldn’t talk to each other, so we couldn’t get an IP and thus couldn’t get online. My wife (who works from home and thus needs VPN access) called the ISP and got things settled sometime yesterday morning.
Now hopefully I can post about something other than what’s wrong with this blasted site.
I thought about just putting this in a comment to my last site problems post, but I figured it would be more visible as a new post. It seems every time I think I have things settled around here, something else pops up that goes wrong. An observant Faultie e-mailed to inform me of a few bugs that have cropped up in the move to WordPress. Investigating his issues led me to discover a few more, and hopefully by now they’ve all been squashed. We can all thank Tim from Germany for his attentiveness. (Thanks, Tim!)
First of all, I noticed that nothing on the page but the header image was showing up in Internet Explorer. The site was loading fine in Firefox (which is what I use 99.999% of the time), so it had to be some silly browser cross compatibility issue. WordPress prides itself on being XHTML compliant out of the box, so I figured it had to be something stupid that I did. Sure enough, I ran the site through the W3C validator and it came up with a bunch of errors, all of which were my own doing. I corrected all of those until the validator said the site was clean and retested it in IE. Predictably, it didn’t work. I had a hunch that it might have been the JavaScript I inserted into the page to let the Ben vs. Darth Vader video pop-up work, so I temporarily removed that from the page. Bing! IE was working again. I tweaked the <script> tag to make sure it was valid and tried again. IE failed once again. After a good deal more researching I found that while Firefox will let you have an empty script tag (i.e., <script src="scriptfile.js" type="text/javascript" />), IE won’t. IE requires you to have opening and closing tags for scripts (<script src="scriptfile.js" type="text/javascript"></script>). With that change made, IE miraculously loaded the main page. I then discovered that I had put the script tag numerous places, so I had to track each one down and remove it and put the script tag into the header template so it would only be included once. One bug down.
Now to get to what Tim actually e-mailed me about. He stated that when he tried to switch the Atom feed to the new URL, the feed broke. The only way he was able to get the feed to work was to put the IP address and port number instead of the domain name into URL. NetVibes required this change to work, but it worked as originally stated in Firefox. He theorized correctly that this had to do with how my dynamic DNS uses HTML frames to redirect HTTP requests, as previous described. Undoubtedly Firefox could work around that issue but NetVibes couldn’t. (And of course, I tested the feed through Firefox.) The obvious solution of using the IP instead of the domain is not a good one, of course, since I’ve already stated that I’m on a dynamic IP block, which would break all these links at my ISP’s whim. The best solution that I can think of to this problem is to use the domain but leave off the “www” and add the port. This would make the RSS 2.0 feed URL http://jeffdarlington.com:8081/?feed=rss2 and the Atom feed URL http://jeffdarlington.com:8081/?feed=atom. This still isn’t ideal, as I’m hoping to eventually rectify this whole DNS-forwarding, framing, port-forwarding mess and make it more normal, but it should work for now even if my ISP changes my IP. Of course, the old URLs should hopefully still work; the rewrite rules automatically forward to the new URL.
Next came commenting. Tim originally intended to add all this in a comment, but couldn’t find the link to register. Silly me apparently forgot to check the checkbox (which, in my defense, is rather tiny and buried deep in an options page) that allows people to register. I checked the box, updated the settings, and loaded up another browser to check the registration link. Unfortunately, I’ve now found out that WP sends you a temporary password via e-mail when you register. Being behind a dynamic IP makes sending server generated e-mail a hit-or-miss ordeal, as many spam filters and relay servers block dynamic IP blocks. I’ve already encountered this problem with the Store several times, and as yet don’t have a good workaround. I tried registering a comment login with a different e-mail address, but so far I haven’t received a response. There’s a good chance this e-mail verification will be the nail in the coffin for comments here, so I’m afraid I’ll have to disable them completely for the time being.
I’ll keep debugging and see what else crops up. Thanks everyone for your patience.
In addition to switching blog software, I’ve been quietly making a few other changes on my little Linux box lately. For one thing, I’m changing the authentication scheme for SSH from simple passwords to public key authentication. Only a few friends and family have direct access to my Linux box, so it only affects a few people. However, given recent events, I feel somewhat justified in ramping up my security.
On the off chance you might have read this into the above statement, no, my network hasn’t been hacked. No advance GPF strips or story notes have been swiped from my hard drives. (Somehow, I detect a definite sense of mixed feelings from some of you, including relief and disappointment….) But my oh my, have they been trying. Not that I think it’s a directed attack by any means, but I have had a number of break-in attempts over the past few months, and they seem to escalate frequently.
Like I’m sure many Linux admins do, I run logwatch daily. (Actually, it seems to come pretty standard with an install of Fedora Core, but if I ever switch distros I’ll make sure to install it if it’s not a default.) logwatch runs through most of your system logs and generates a single, combined report summarizing the health and status of your computer and plants an e-mail in your root mail inbox every morning. It covers just about everything, from crons, Web and FTP logs (especially errors), mail, system messages, automatic updates, and (especially for the topic of this article) security logs. It was because of logwatch that I discovered that Demeter’s hard drive was failing last year and had to be replaced (more SMART failures, surprisingly undocumented either here or in the GPF News, and completely unrelated to Apollo’s crash; last year was not a good hard drive year for me). It’s through logwatch that I watch various IIS-targeted worms periodically bounce harmlessly off of Apache (which I take a small dose of perverse pleasure in). And it’s through logwatch that I sit nervously and watch the almost daily hack attempts to break into my system.
Having any computer on the Internet is a dangerous thing these days. I certainly don’t want to alarm the less tech-savvy of you out there (the last thing I want is to discourage people from getting online), but any computer connected to the Internet is under a constant barrage of probes and pings. Most of these are harmless and often routine, but a growing number of them are malicious. Hackers are constantly scanning the Net for connected systems that may have vulnerabilities that can be exploited. Over the years I’ve grown more and more curious about Internet security, and I’m finding myself get more and more paranoid about how insecure much of the Internet really is.
Having a server on the Net is just asking for trouble. They are under a constant assault, being poked and prodded from all sides and on every port. Most regular users have a small amount of anonymity through the dynamic IPs of their ISP. Servers, on the other hand, are meant to be found, waiting for requests (as their very name states) to serve. By their very nature they advertise themselves with domain names saying, “Here I am! I’m here to help you.” Being so public, they make themselves more visible to attack. While some black hat hackers target specific hosts looking for various bits of sensitive personal or corporate information, most of these hacks are actually pretty casual: simple probes looking for any random vulnerable system that can be broken into. Perhaps they may find something useful to exploit, like financial information or blackmail material. But my theory is that they are mostly looking for new weapons to add to their arsenal, additional zombies to add to their growing botnet collection.
Virtually every day, my logwatch report comes up with at least several hundred break-in attempts via SSH. On especially nasty days, the attacks can range in the thousands. Gaining access via SSH is more advantageous than other means, as it gives you direct command-line access to the system which is also encrypted end-to-end, preventing eavesdropping by anyone in the middle. Needless to say, unencrypted telnet is completely disabled on my system.
The good news for me, at least, is that I’ve taken quite a few precautions to prevent these break-ins. The first and probably most important step is to prevent root from logging in via SSH. In order to gain root access, an attacker must first compromise another login, requiring them to break two passwords instead of just one. This adds an extra step for me when it comes to my admin duties, but that’s an extra step I’m definitely willing to make. I’ve also limited which logins can access SSH to a specific group, into which are placed only users that I want to explicitly grant such access. This greatly reduces the number of available logins that can be compromised. (Most of these attacks try various combinations of common user names, so odds are they have no clue what user names may exist on the machine.) The next big step, though, is to require public-key authentication. This means that those with console access not only need a password but a digital private key, and only the combination of the two will allow someone in. This is the form of authentication SourceForge uses for access to their build and test environments, and it’s probably the most secure method freely available (usually implemented via OpenSSH).
Setting up GnuPG keys, securely wiping old hard drives, and now locking down my Linux box with strong-grade encryption… I’m quite the paranoid little thing, now aren’t I? Does everyone get this paranoid in their old age, or is it just me? If you know the answer, you know where my public key is….
Edit April 2, 2007: I tried to make a follow-up comment to this, but that obviously didn’t work. So I’ll just edit this post to include a link to this analysis malicious SSH login attempts article I just found. It made my flesh crawl a little. In addition, check out the following Linux.Com articles on beefing up SSH security. Thankfully, I’ve already discovered that I’m doing most of these tricks already, which made me feel just a tiny bit more secure.
No, you’re not seeing things. Neural Core Dump should be looking quite a bit different now. After a lot of investigation and some pretty complicated Apache configuration file tweaking, I’ve moved the blog from using Movable Type to WordPress. Not that I’ve had any serious issues with MT; it has served me rather well the past couple years, and I’ve been reasonably happy with it. I primarily picked MT over the other options out there because (a) I wanted to host my own blog and not have it on some big mega site like Blogger or TypePad and (b) I had heard good things about MT (as one person put it, it’s “real blogging software”). However, the recent problems with the site (admittedly not MT’s fault in any way) have caused secondary issues (like the inability to post comments) that have made MT less functional for me. Plus, I like to think of myself as a closet Open Source advocate (see the advocacy question in this old NewsForge interview), and WP is Open Source all the way. (MT’s source is available, of course, seeing as it’s primarily Perl with a dash of PHP, but strictly speaking it’s not Open Source.)
Now for the nitty gritty. I’m sure you’re asking, “How does this affect me?” Hopefully, it won’t affect you much, if at all. The aforementioned Apache tweaking has been mostly mod_rewrite directives to allow old links (both internal and external) to continue to work. If you have old links or bookmarks that point to posts made on the old site, those links should continue to work. (I can’t, of course, guarantee that they’ll work indefinitely, but I tend to be more obsessive about maintaining old links that most webmasters.) However, I’d recommend that you use the new permalinks generated by WP in new links and perhaps update old links to ensure the best compatibility. Note that this also affects the various XML feeds like Atom and RSS; WP puts them in different places than MT and the rewrites should allow the old MT feeds to work, but I’d suggesting changing your feed URLs.
Commenters will notice that we’re no longer using TypePad authentication. Thus, any old logins you may have created to comment here in the past won’t work here anymore. (They should, of course, continue to work on other TypePad-authenticated sites, so I wouldn’t abandon them unless you only used them to comment here.) You’ll need to create a new “subscriber” account here on this site in order to comment. Comments are still moderated, but once you’ve made your first moderated post you should be able to make additional posts without any trouble. WP has a number of comment spam features, so I may have to dredge the filter occasionally to make sure no comments get inadvertently filtered.
TrackBacks and Pings are still disabled. Still haven’t found a good use for them to offset the potential spam abuse.
WP seems to be noticeably slower than MT. This is likely because WP is purely dynamic PHP while MT builds static HTML pages. I’m not sure how much I like that, but I plan to keep using WP for a while to see how well it seems to handle the load.
Expect plenty of hammering, sawing, and general construction work as I continue to fiddle and tweak. While the conversion should be largely complete, I’ve got a whole new system to figure out, so things are bound to change.
I was beginning to wonder why there weren’t very many comments lately. Not that I tend to post all that frequently, and I’ll readily admit my recent posts may very well have had little meat to them worth commenting on, but I thought at least the Geeklet Lullaby would have drawn some attention from some GPF forum regulars. Now I think I know why you guys have been so quiet.
I went to post an amendment comment to the recent site problems post to state why I think things were happening a certain way when I noticed that TypeKey was not remembering my login. Naturally, I clicked the link to sign in. I was directed to the TypeKey site, put in my login credentials, told it to remember me for two weeks, and clicked the button. I was redirected back to the blog… where it told me I wasn’t logged in and it politely asked me to sign in again. Some deep, dense Neanderthal-laden DNA entrenched somewhere in my genetic code responded with, “Duh… I’ll try it again.” (Okay, maybe it’s not so much of a dunderhead response; I’ve worked with computers long enough to know that some things are unpredictable–even when they’re coded not to be–and you ought to try it at least a couple times first to make sure the problem is reproducible.) So I clicked the link again. TypeKey dutifully remembered I was logged in and didn’t prompt me for my credentials this time. Instead, I was sent directly back to the blog… where I was told I wasn’t logged in.
I’m hoping that some of you by now are saying this sounds familiar. (If not, then I’ll start feeling very lonely.) Here’s what I think has happened, which in part will include the aforementioned amendment. I’ll assume you’ve already read the previous recent site problems post. (If not, you know where to find it.)
As previously mentioned, my dynamic DNS service is currently set up to forward the domain “www.jeffdarlington.com” to my Linux box on the port 8081 since my ISP has blocked access to port 80. Well, I found out how they make this work. If you try to view the HTML source of the main blog page, you’ll discover that it consists of a frameset with only one frame, whose source attribute points to the raw “IP:port” address. This frameset HTML is served by the dynamic DNS. What you see appears to be the main page of the blog filling the entire browser window; what you get is a page from the dynamic DNS holding a frame that points to the blog page. Inside that frame, the browser thinks everything is referenced by the “IP:port” address, not “www.jeffdarlington.com”. TypeKey is set to respond to the domain name, however, so it doesn’t recognize the raw address. Thus, when you get back to the blog after signing in, TypeKey says your authenticated to post at “www.jeffdarlington.com” but not at “IP:port”, so it continues to insist that you must sign in.
I’m not sure if there’s a workaround for this issue. I’ll see what I can do, but I can’t promise anything. I could see if TypeKey will allow authentication on the IP, but if the ISP changes my IP we’ll be back to square one. I think for the time being that we’ll just have to put up with having no comments until a more permanent solution can be found. That permanent solution may require me to buy Web space somewhere, but I like the flexibility of hosting this site myself. I might be able to convince Keenspot to host the blog, but then I’ll need to include ads to offset their bandwidth. (I’d also have to come up with a way for Keen’s automated ad rotations to work with Movable Type’s static pages.)
The good news, at least, is that it appears that the various RSS and Atom feeds seem to work correctly, at least when I access them directly from Firefox. This should mean that those of you watching this via the feeds should still be getting posts. However, if you need to comment, though, I’m afraid you’ll be stuck with the GPF forum or regular ol’ e-mail for now.
If you’re reading this post, congratulations. That means our recent site problems have been resolved… at least for the moment. Below is the rough rundown of what happened this weekend, for those of you who care. There’s lots of technical jargon below, so if you don’t care, feel free to blindly ignore the rest of this post and live in ignorant bliss. Trust me, it’s probably a safer place to be.
For those who didn’t already know, this site and the gpf-comics.net domain are both hosted on my personal Linux box behind our cable modem. This was originally intended as an experiment to teach myself the ins and outs of running a Web server (specifically Apache), but over time it morphed into a cheap form of hosting that gave me complete control over the hardware and software involved. Keenspot hosts the main GPF site and they do a very good job of it; but to be perfectly honest, I have no clue what hardware they use, only a hunch about the software (because I have SSH access), and I couldn’t tell you for the life of me where the server is located. I like having directly physical control over the GPF Store (which is back online, BTW), which gives me a lot more confidence in what happens to my customer’s data. I also like knowing how things work.
My Apache setup is moderately complicated. I briefly touched on it before, but I’ve been using a number of virtual hosts to serve several sites on the same machine. The blog and the Store are the main sites I run, but I also have a number of other domains that I’m currently sitting on and forwarding to other places with the intent of using them for future purposes. Apache happily listened to all these requests and parceled out the right stuff to the right people without breaking a sweat. Until this weekend, that is.
Unfortunately, I think the success of this blog was part of its undoing. I haven’t looked at the logs to confirm it, but I think the recent “Ben vs. Darth Vader” post brought a bit of unwanted attention from my cable service. The increased download traffic probably caught their attention and they blocked port 80 to my IP. One reason I strongly suspect this is that my SSH access didn’t go away and I could still access the Store using the HTTPS port, so I knew Apache and my Linux box were up and they were still online. I tried a number of workarounds throughout the weekend, working in small batches here and there during stolen moments, but each fix seemed to break something else.
At the risk of revealing to my ISP what I’ve done, here was the winning solution. My dynamic DNS service lets me forward HTTP requests to different ports transparently. Since port 80 was blocked, I forwarded gpf-comics.net to port 8080 and jeffdarlington.com to 8081. (I couldn’t forward them both to the same port, because this redirect seems to strip the domain name from the request and only feeds Apache the IP, thus making name based virtual hosts moot.) The other domains, which were originally just being bounced by my Apahce, are now being forwarded directly by DNS2Go so they never reach my box. Since HTTPS seems unaffected, it’s currently still pointing to the same place. The good news is that most of your bookmarks and links should continue to work, so don’t change them (in case I need to tweak the configuration again). The caveat is that if you’ve been using “jeffdarlington.com” to access this site instead of “www.jeffdarlington.com” the redirecting will probably break. The redirect only works with the “www.” so please use that URL.
I’m not sure how many of you follow User Friendly, but I’ve been a loyal reader ever since I first discovered it. Ironically, that occurred when a reader sent me a nasty-gram accusing me of ripping off that strip; I never knew it existed before then, and my investigation of the site kept me reading until I finished the archives and added it to my daily reading list. Since then, I’ve gotten to meet Illiad in person and continue to exchange messages with him periodically. I consider him a comrade in arms when it comes to webcomics… he and I are some of the last of the “old skool” “techie” comics still around, so it feels good to have someone to occasionally sit around and complain with about our creaking bones and aching joints. If you’re reading GPF but aren’t reading UF, you’re depriving yourself of some seriously funny geekery, and I highly recommend you correct that oversight as soon as possible.
Anyhoo, the UF site has had a Link of the Day feature for years now (a feature I’ve thought about stealing), and they often find some interesting geek-related gems from across the Web. Recently they had a geeky number game that spawned a collaborative effort on the GPF forum. Today’s link happens to be a “websites as graphs” applet that generates a visual representation of the HTML behind a given Web page. Ordinarily, I don’t get into those goofy “Which soggy breakfast cereal are you?” games that are so prevalent on blogs, but I thought this was such a novel and geeky concept that I couldn’t help myself. I typed in the URL to GPF and it produced the following graph (click to see a larger version):
The legend to all the little nodes is available on their site. Sadly, it’s rather telling about how old my HTML “sk1llz” are; I seem to be stuck way back in old HTML 3.2. Note the abundance of red nodes, which are table-related tags, and the conspicuous lack of green nodes, which are HTML 4+ DIVs. Since yellow represents forms, I’d say the huge yellow ball at the top is the storyline drop-down box, while the smaller yellow ball in the lower right corner is the Keenspot drop-down at the top of the page. The blue and gray ball near the bottom is probably the “site links” block (that dark blue block of links that sits near the bottom of every page). The graph looks like some sort of weird abstract dog/gecko/scorpion like thing, doesn’t it?
Continuing my curiosity, I ran this site through the applet (which of course does not include this and subsequent posts):
Being largely automatically generated by Movable Type, there’s very little hand-coded HTML here, so it’s more up-to-date with the standards. I think the red ball near the bottom is the calendar, which is the only instance of a table on the page. The origin point of the graph (the black dot, which represents the HTML tag, right below the little gray cluster in the middle of the “neck”) suggests that the left side of the graph is the side bar with the calendar and most of the links, while the upper right cluster is the main body of content, blog posts and such. Looks more like a strange spacecraft to me, less organic than GPF’s graph. I wonder if that’s a factor of how GPF is largely hand-coded while this site is more automated.
Not exactly the most exciting entry, I know, but it amused me enough this morning that I took the time to snatch the screenshots between wolfing down my breakfast and shoving a bottle into Ben’s mouth. The owner of the site encourages site owners to post their graphs on Flickr; I doubt I will as I have no other use for that site, but taking a look around at some of the interesting graphs they have is quite interesting.
I feel kind of bad apologizing again since that’s how I started the last post (although I think most of you would admit I had a very good excuse for why I hadn’t updated earlier in that case). But I thought I also might take a minute to explain what’s been going on with the blog here, and why it’s been up and down like a hyperactive carnival ride lately.
As recently mentioned, we’ve just moved into the new house here in West Virginia, and we’re still getting settled in. Of course, being the geek that I am, one of the first things that got set up in the new building was the home network. I even came in after closing and before the movers arrived and tested the placement of the wireless access point to see what kind of WiFi signal we’d get. (I’m happy to say I’m getting a stronger signal here than in the house in North Carolina; must be less interference.) We had to wait a few days before the cable company could come in and set up the cable modem, but once they did we were online in no time.
Well, as the observant of you may have noticed, this blog (along with the GPF Store) is actually hosted on my personal Linux box behind said cable modem. (Dynamic DNS is a wonderful thing.) Thus the blog and Store are dependent on this connection and were down in the week or so it took to break the systems down, move them a couple hundred miles, and wait for the cable setup. Not a big deal, as I warned you guys that was coming. As soon as the home network was established, up went Demeter (the Linux box) and the dynamic DNS, and we were back online.
Or so I thought.
I had gotten into the habit of checking in on Demeter periodically during the day from my day job. You know, SSH in, run yum to download updates, check Demeter’s overall health, peek in on the house webcam, etc. However, I started noticing that there were times I couldn’t get in, like the DDNS wasn’t working or Demeter just wasn’t up.
At first I thought it was purely a cable modem issue. Unfortunately, I think our new cable company isn’t quite as reliable as the old one. Judging from the problems our parents have had with their cable modems, it wouldn’t surprise me. My parents’ is ridiculously slow and has a tendency to completely flake out and need the power cycled to recover. Sure, we had the occasional problem with our NC modem, but not the problems we’ve seen here. However, while I’ve caught our cable modem needing a reset a few times, that hasn’t consistently been the problem.
I’d get home after work and notice Demeter seemed to be locked, not responding to mouse or keyboard commands or showing anything on the monitor. The only way to recover from it was to force a hard reboot. Definitely not a good thing for a Linux system, but I have yet to knowingly lose any data. Knowing that we’ve had a few power failures lately (more since we’ve moved into this house than I think we’ve had all year at the old one), I went ahead and sprung for a UPS to make sure Demeter wasn’t going down unexpectedly and failing to recover gracefully. When I caught her doing the same thing after the UPS was installed and known to be fully charged, I knew something else had to be the problem.
So I’ve been pouring over server logs, looking for anything that could be the problem. Nothing seems to show up. I added a small cron that reboots the machine every morning, and that’s helped, but hasn’t solved the issue.
Then I noticed the other day that the machine was up and running, but not responding to the network. The loopback address was working fine, but Demeter couldn’t see the router, any of the other machines on the LAN, or the Internet at large. Every time I tried to look at the network service daemon, the status check would lock up. I rebooted and that seemed to solve the problem, at least for the moment.
I added another cron to go in and restart the networking daemon every hour. That seems to have done pretty good so far, as Demeter seemed to be accessible pretty much all day yesterday. I’ve since scaled back this network restart to once every two hours, hoping that wouldn’t be quite as much overkill. I’d be tempted to suspect that Demeter’s NIC is going bad, but since restarting the network service seems to fix things, it doesn’t sound like a hardware issue. However, I can’t find anything in any log on the system that seems to indicate anything is going wrong, and I’m wondering if the fact that these symptoms didn’t appear until we moved to WV is a coincidence or not.
Anyhoo, I thought I’d let you know what was going on. I don’t have a long term fix for the situation, but my little stop-gap measure seems to be doing the trick at the moment. While I’m a Linux and Open Source proponent, I’ll readily admit I’m not an expert. I’ll keep poking around to see what I can find, and if anything interesting crops up, I’ll try to mention it.
I’m not going into all the gory details here; I’ll just redirect you guys to the thread on the GPF forum that I just started. Long story short, I’m having all sorts of problems with the Apache configuration of the GPF Store, and I’ve exhausted all my personal knowledge and experience. You can read the thread for the specifics. Any input anyone can share would be greatly appreciated.
Update: I. Am such. An Idiot.
I thought I had searched the configuration directories thoroughly, but undoubtedly not thoroughly enough. It turns out httpd.conf is under /etc/httpd/conf, but I forgot all about the included files under /etc/httpd/conf.d (and searching under /etc/httpd/conf isn’t exactly going to find those files, now is it?). And I forgot I also had to tweak /etc/httpd/conf.d/ssl.conf, because I had to add similar RewriteRules to “close” the store under HTTPS. Sure enough, there they were. I commented out those rules, restarted Apache, and everything worked.
Thanks to M70X on the forum and to the Faultie who individually e-mailed the same suggestion. All’s well that ends well. Now I just have to rewrite that section of the news update before it goes live.