System update

August 19th, 2010

A major milestone was accomplished yesterday: *everything* on agora has been copied to the fileserver, and what isn’t now residing there is getting backed up there nightly.  Including email.  For now ;-)

The next step will be some minor technical internal changes to make the fileserver properly replace the two big disks, and probably start migrating web sites to the new web server.  That will take a while, and I’ll be out of town Aug 28-Sep 6 (so any real checks won’t be processed right away — you’re best off using the online payment which gets processed automatically!).  After I get back, I’ll work on bringing the new shell server online for real, now that it accesses the same home directory.

Finally, moving email to the new email server should allow agora to be retired, and we can finally move forward!

Agora stability & fileserver move update

August 16th, 2010

Agora wedged Saturday night, oddly enough not as a result of file copies or filesystem corruption, however problems with the /home filesystem keep it from being cleaned up after a crash, which resulted in extreme instability until I manually forced the cleanup this morning.

With a stable system, I was able to start actively migrating home directories, and all user directories are now on the fileserver.  I’m currently in the process of moving web directories, and when that’s completed, I will be able to take this drive offline and proceed to the other large drive, which holds email and other system files.  We’ll get there!

vmhost ssd failed

March 14th, 2010

If it’s not one thing, it’s another: the SSD disk the vmhost runs on has developed bad blocks and the system is basically non-functional.  I have a spare and will get the system rebuilt, but that’s going to throw a kink into working on agora.  I’ll do what I can…

Unstable today

March 14th, 2010

I’m going to be copying files off agora and thus tickling the corruption and crashing the system a lot today.  Hopefully I can get things moved around to get things stable, though the new server is acting up today, more on that when I get in and take a look at it…

System stability

March 13th, 2010

I’ve swept out some of the cruft from agora’s filesystems, which should hopefully keep it a little more stable today, and I’ve installed a new kernel that allows remote mounting the new fileserver to make it easier to migrate off this antique.  That kernel is a slightly different version than the rest of the system, so a few things (like ps and w) aren’t working.  I have to head up to Portland for the evening, but I’m planning on spending tomorrow getting the data off the bad disk and cleaning up the issues with the kernel version.

New spam filter “quirks”

February 2nd, 2010

Some quirks with the Red Condor spam filter:

1. The Red Condor does not play well with text mail clients and web browsers. It’s heavily javascripted and requires web browsers that support it. The email messages are HTML’d and while they can be set to text mode (from a gui browser), that consists basically of a very long link to the web interface that would need to be cut/pasted — you wouldn’t want to type it!

2. Before users can login directly to the RC, you have to go to http://redcondor1.peak.org/console/ and click on the “Signup” link. This asks for an initial password (twice), then sends a confirmation message.

3. When users get a quarantine message, then click on the Personal Dashboard link, the default view is for “messages quarantined today” whereas the email message will have “messages quarantined yesterday”. You have to click on the Time Range button to get the slider control that allows changing that.

4. When you “Release” a message, it will prompt you as to whether or not you want to tell Red Condor they goofed and whether or not you want to whitelist the sender (”modify friends list”).

5. You can’t adjust the sensitivity, only adjust how the different categories are handled (this is done in the Policies tab):

Green (Junk): “legitimate” business/newsletter/mail list etc
Yellow (Suspicious): blank, forged, foreign, attachments
Red (Dangerous): everything else that doesn’t look good

It’s pretty flexible on how you deal with the various types (for example, you can handle messages in specific languages differently), but you can’t adjust *how* it categorizes messages.

6. If you tell it to send a periodic digest, it *will* send you a digest. You can tell it to limit the zones it reports, but all that does is change it so it gives you a count instead of listing them out.

7. All domains were switched to the Red Condor at once by changing the dns for barracuda.peak.org to point to the Red Condor systems. An unfortunate side effect of this was that the links in the Barracuda spam digests that went out today (and previously) go to the Red Condor instead of the Barracuda. There are two aspects to this:

A. To get to the Barracuda, edit the url to barracuda1.peak.org instead of barracuda.peak.org. The Barracudas have been reconfigured to use that in the links in the messages sent out from now on.

B. The Barracuda redirects users to http://barracuda.peak.org/login This url does *not* have the signup link. Only /console has the link (e.g. http://barracuda.peak.org/console/ orhttp://redcondor1.peak.org/console/)

8. We are still working an issue to get SSL working on the Red Condor; at the moment, if you go to https://redcondor1.peak.org, you will get an untrusted certificate error, then after you connect, it will redirect you to the non SSL url anyhow. This should be fixed in the next couple of days.

vmhost restored

September 4th, 2009

The vmh server was restored around 7pm and all vms restarted.  Let me know if there are any problems…

vm server lost disk

September 4th, 2009

The flash disk the virtual machine server runs on has failed; I’m reinstalling on a new disk now.  Systems should be back up in a couple hours…  (one of the nice things about virtual machines!)

Network outage

June 25th, 2009

Peak replaced its core routers last night, and in the process, the route to my network got lost due to an obscure configuration issue.  It should be fixed shortly…

New shell.rdrop.com nearly ready

June 14th, 2009

I’m finishing up the next step in the process of retiring the antique system that is the current “agora”: a new shell server.  It can be accessed at shell2.rdrop.com, or at shell.ipv6.rdrop.com (or, shell6.rdrop.com for easier typing).  Yes, Peak has IPv6 connectivity, and I’ve started adding connections to the various systems.  When you login to the new system, you can “ping6 ipv6.google.com” and be doing the latest and greatest internetworking!

When might you be able to do that?  Well, technically, now.  Logins are enabled, however, I’ve just started copying /home from agora to the file server that the shell server now uses, so you won’t have a home directory, or all of your files, until that completes.  And many of the tools you use are probably not installed yet, and it’s a Centos system instead of FreeBSD, so it’ll be a little different.  Getting logins to work with the database backend has been the hard part, however, and now that that’s operational, the rest is nearly trivial…

So the bravest of you can give it a whirl now, and once the files are all copied in a day or so, I’ll get some of the basic addons installed and then it’ll be in a proper Beta state for real testing before making it the production shell server…