As a small hosting, systems administration, and programing company we’re on the front lines of Internet security. In the old days (oh, say pre 2003) our security focus was on upgrading and protecting the server’s operating system. Hackers would probe servers, find vulnerable applications (Apache, portmap, sendmail, etc.) and compromise the machine in the hopes of gaining root access.

Not any more.  Hackers could care less about the OS.  They attack web sites since a compromised web site provides them nearly everything they need; the ability to send spam, find user data, and attack other computers.  And hackers tend to reach for the low hanging fruit – web sites that run out-of-date open source software such as Joomla, WordPress, and Drupal (among a host of others.)

Continue reading Web site security for the common web site owner →

What is Clustered Hosting you say?  It’s the top-of-the-line shared hosting service that we provide to clients that need high scalability (i.e. those with high traffic sites that a dedicated server might not be able to handle) but who don’t have the budget or technical experience to set up their own scalable server solution.

In a normal, shared hosting scenario ($8.95 per month), we place up to 200 web sites on a single server.  Though this may seem like a lot of sites on one server it’s actually far fewer than large, volume-based providers typically place on a theirs.  With Clustered Hosting ($99 per month) we currently have seven servers that host ten web sites.  Yep, that’s less than 1.5 web sites for each server.

Continue reading Easy, big-time scalable web hosting: Clustered hosting →

My Mom has a vague idea.  So does my wife.  My kids think we fix computers, eat candy, and watch the fish tank – none of which I can deny.  Our clients usually know some of what we do, if we do it for them.   With the exception of myself, my staff, and a very small sub-set of our clients who utilize all of our services no one knows what the heck we do.  So here goes:

Continue reading What the heck does Brownrice do? →

Geek alert!  Only read this post if you are massively geek/developer oriented!

A client emailed in this weekend to find out why their recently imported database data was displaying weird symbos for any place of their sites “higher level” characters.  We’ve done a lot of character encoding work for our biggest client and feel we know our stuff in this realm.  As such we prefer to set up our Apache web servers, and PHP installs, to use the UTF-8 character set.  After a little research by us, and the customer, it turned out that their database data was encoded in iso-8859-1 so symbols like á would look like this: ®

Like usual, we instructed the client to insert the directive below into an .htaccess file:

AddCharset ISO-8859-1 .php

But it didn’t work.

After testing on a couple of different servers it turned out that PHP, and only PHP (not Apache), controls encoding on PHP files.  This seems like a no-brainer in retrospect, but it had Dave and I confused for a bit.  At any rate, this is what one does to override the character set in an .htacccess file for PHP files:

php_value default_charset ISO-8859-1

We’ve added this to our support FAQ for future reference as well.

If you’ve been playing in your virtual server you might notice this type of entry in /var/log/messages

Feb 11 12:21:10 load1 sshd(pam_unix)[397]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=mail.kwpskt.edu.hk  user=root
Feb 11 12:21:10 load1 sshd(pam_unix)[398]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=mail.kwpskt.edu.hk  user=root
Feb 11 12:21:11 load1 sshd(pam_unix)[402]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=mail.kwpskt.edu.hk  user=root
Feb 11 12:21:11 load1 sshd(pam_unix)[404]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=mail.kwpskt.edu.hk  user=root
Feb 11 12:21:12 load1 sshd(pam_unix)[406]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=mail.kwpskt.edu.hk  user=root
Feb 11 12:21:13 load1 sshd(pam_unix)[412]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=mail.kwpskt.edu.hk  user=root

Those lines are bad guys trying to get into your machine via brute force dictionary attacks.

If you maintain good passwords there’s little to worry about here.  However, if like me these things annoy you there are a variety of ways to get rid of them.

Continue reading Keep those pesky SSH attacks at bay →

Dumb.

Over the last year we’ve significantly upgraded the power distribution within our mini-data center.  However, as often is the case when things are upgraded, we hadn’t yet worked out all of the kinks.

Yesterday, I upgraded the Brownrice phone systems by bringing a new Asterisk server online.  Apparently I plugged this machine into a circuit that was nearly overloaded.  All of our machines perform routine maintenance between 4am and 5am each morning, when most people are sleeping.  This causes the machine’s load and power consumption to increase.

This morning, because of the added Asterisk server load, one of the data center circuits blew.  Our batteries kept things running for a bit but eventually a few servers went down and, most importantly, one of our primary switches lost power.   (If the power was cut to the building our generators would have kicked in, but the power supply was not affected.)

As we are a small hosting provider we don’t have a technician in the building over night.  (If we did this person would have nothing to do 99.99% of the time.)  Dave came in, sorted it out, and stabilized us.

We’ll be spending the day analyzing our power distribution to prevent this from happen again (yes, its happened once before) and that if it does happen again we’ll make sure that the outage will be minimized (think: switches and routers on their own circuits.)

I’m very sorry for the outage and thank you for your business.

~ Oban

Don’t try and get anything by Dave you bad, bad server. He’s watching.

We’re about to perform a little network maintenance (today, February 1st, 2009 at approximately 2:45 pm MT) which will provide us with an additional layer of redundancy and potentially greater speeds to both coasts.

We don’t expect any downtime, but, well, you never can be sure with tech upgrades!

And by the way, if we expected downtime we’d do this at night.  But we don’t.  When possible we like to do this type of thing during the day when we’ve got more eyes, and better rested eyes, watching the chicken coop.