Recently in Announcements Category

public dns resolver being restricted

| | Comments (0)
I've put this off as long as I could.  Circumstances are forcing me to do this.

I'm locking down resolver.gigo.com, the public DNS resolver I've been operating for friends and family.  It will soon be restricted to answering to just specific IP's.   If your host (or router) are using  216.218.228.114 for a DNS server, this affects you.  (You can also try visiting http://test.gigo   - if that works, it means you areusing my resolver).

I'm still happy to resolve for you and your house - just let me know what IP/IPs I need to open up to.


Mail issues.. antivirus upgrade needed.

| | Comments (0)

Apparently, the antivirus software that we used (clamav) decided to tell us that it was out of date - by breaking mail.


http://www.clamav.net/lang/en/2009/10/05/eol-clamav-094/


I've upgraded, and mail appears to be flowing again  - the backlog from today is being processed now.



Server bandwidth increased

| | Comments (0)
Our colo provider made an offer I couldn't refuse.  

We're now able to do 100 megabit full time, without fussing with "95 percentile" stats, for the same price as I was paying (in exchange for a new 1 year commit).  Since I love their service, it was a no brainer. :-)  HE.NET++.

Hard drives upgraded

| | Comments (0)
Dec 22-23 2009:   Hard drives replaced; now 678 gigs usable free space for home directories and web sites.

Note, access may be a bit slow for the next 48 hours as mirroring and other activities bog the machine down.  However, at this time I don't anticipate any further reboots or crashes.

-jason

GIGO.COM Maintenance - Dec 22, Dec 23

| | Comments (0)
Sometime Tuesday afternoon on Dec 22, gigo.com will be going offline, to upgrade the hard drives.
Unfortunately, I can't do this with a live system.  Downtime will be a maximum of 24 hours, however, I expect it to be far less - perhaps a few hours.

I will maintain status info at http://status.gigo.com .


Partial HW update over xmas

| | Comments (0)

File space usage has grown significantly since our last server upgrade. I expected the current disk space to hold us for 4 years, which is about what I budget for the overall hardware. Alas, it is looking like perhaps I should upgrade the storage sooner.

The fun part is, gigo.com currently is comprised of 5 disks, but realistically only 250 gig usable space to end users. We spend a fair bit on redundancy, in case of catastrophy. Here is how it is broken out:

  • disks 1+2: main system, this is where the main files are stored, and served from. Anything we do happens here. This is continously mirrored, so that if either disk fails, the system can quickly recover and keep running. And, I can put in a replacement to restore redundancy "hot".
  • disks 3+4+5: Backups. At any given time, 2 disks are hot and mirrored; and 1 is cold (offsite, my house). Periodically, I take the cold disk, stop at the colo, swap out one hot disk for the cold one. The server will resync the mirror, and the disk I have in my hand goes back home - with a copy of several days worth of our files. And, total time in the colo is <10 minutes to sign in and swap a disk.

With that in mind, if I do upgrade storage, I'm not upgrading just one disk, but realistically all 5. Ooof!

What I'm looking at doing is:


  • 2 enterprise class SATA 1GB disks - $160 each + the governor's ransom - matched set for mirroring.
  • 3 desktop class SATA 1.5GB disks - $120 each + the governor's ransom - matched set for mirroring.

The backups can be desktop class; they get hit with less work, don't need to be as fast, and we can afford a failure there without a serious panic. They should however be larger than the main system drives, since we backup multiple days worth of changes (currently we back up ~20 days worth of changes; this number varies based on space available and number of changes made in a day).

I'm looking to try and help raise about half this cost - so a target of $375. If you're a significant user of gigo.com and can help, please contact me. Lady Visa will be covering the gap; I'm aiming to do this hardware changeout over the xmas break.

SSH server abuse

| | Comments (0)
Something started about 2 hours ago here; ssh scans for user "root" hitting all public IP's for gigo.com.
Looking at it with a packet sniffer, all IP's get hit in parallel; sometimes without port randomization from the other side.  Looking at the hosts, looks like they all have old sshd's running.  Can't even blame windows this time.

Expect connections to gigo.com to be spotty - sshd is getting overran.  gigo.com users:  I'd like your feedback on whether or not moving the SSH port would be a big impact to you. If it would be.. what if port 22 was open to specific subnets (ie where you work); or having a web CGI that re-enables port 22 for your current IP?

Spam problem @ gigo

| | Comments (0)
Since midnight something has been posting spam via the web server; I've killed everything in the queue that was going outbound spam. Outbound mail to AOL, YAHOO, etc mail be delayed considerably (They blacklisted us due to the spam).  The entry point for it has been neutralized (and the vulnerable software is now on the ban list here).


imap server updated

| | Comments (0)
..for security reasons.  

Hollar if anything is still amiss.

More SSH scanning countermeasures

| | Comments (3)

This is to users to ssh to gigo.com.

Last year, I enabled countermeasures to help keep the SSH hack attempts against gigo.com down to a minimum. We automatically block the IP address of systems trying to log in to gigo.com and repeatedly failing.

The problems are getting worse; as such I'm making these changes:


  • Attempts to log in as a valid ID: unchanged; 10 attempts and you're banned 15 minutes
  • Unknown accounts and daemon accounts: immediately blocked for 150 minutes

If you log in from another account with a different account name, make sure that you always remember to specify your gigo.com account name (correctly!) or the machine you are connecting from will be blocked for everything but the web server, for 150 minutes. If this regularly affects you, I *can* whitelist specific IP addresses to be immune to this behavior.