Posted for review, comments and entertainment value. If this is interesting, please comment, or just point and laugh; it’s okay.

Casual Sysadmin Hosting Service

“Don’t ignore your domain. We’ll do it for you!”

Service overview

We host a handful of vanity domains for ourselves and friends. We try to do everything as cheaply as possible and we pass the savings on to you.

This service comes with no guarantee. It is pretty much a given that your web pages may be unavailable and your domain-based email may be delayed from time to time, sometimes for a few minutes, and other times for a day or two. It is also possible (though unlikely) that your files may be mangled or deleted, incoming email may be bounced or dropped into the bitbucket. It’s even theoretically possible that a hacker could deface your pages or read your email. You have been warned.

Because the service is not guaranteed, you should take precautions. If you post anything valuable, make sure that you keep a copy for yourself, somewhere that you can get at it. If something really bad should happen to the server, we accept NO liability. We will try to get the server back up, but if we are not able to restore service for your domain, your only recourse is to find alternate hosting arrangements and change your domain registration to point elsewhere.

That said, we are not out to scramble your files or torch your email. We use this service for our own personal web pages and personal email, so we want the service to be up and usable. If something goes wrong, we will try to get everything back up, and we will try to keep you updated. If we have an alternate email address for you, we will email you to let you know what is going on. You can also call us to ask questions, and we’ll try to answer, though we may have to call you back.

Because of the casual nature of the service, we’re casual about payment too. In fact, don’t pay us anything at first. If you’ve kept your domain(s) with us for a year or more, we may ask for a “suggested donation” to offset the server or bandwidth costs. If you do pay us, it should be understood that it’s for the services already rendered and we are not obligated to continue service in the future regardless of whether you’ve paid or not. (If you don’t pay us, that’s fine too… it’s just a suggested donation. If you can’t afford it, let us know. If you don’t think the service was worth it, pay us less or nothing. And if you decide to save your money and go purchase a “real” web hosting account with better service, we will not be offended at all. We promise.)

Who are “we”

Right now “we” means me. In the future I may recruit some sysadmins like myself who also have a server at home (or can spring for a virtual server account) and would like to be part of the Casual Sysadmins Network. Specifics have not been worked out, but if you’re a Casual Sysadmin like me, we might be able to help each other out.

It’s *possible* (though at this point quite unlikely) that this could be the start of a business venture. If that should happen, current users would be invited to be charter members of the new service. The main reason this is “unlikely” is that we don’t intend to provide anything cutting-edge in terms of service or features. If this should become the springboard for a business, what we have learned up to that point won’t be considered proprietary, and any sysadmins who helped us out would be free to use our shared knowledge, tools, techniques, scripts, recipes or documentation for their own purposes as well. Frankly, I would not want to work for a company that doesn’t contribute to the public domain when there is no competitive advantage to keep something private.

Services provided

• DNS service for your domain (not registration fees)
• Web pages for your domain
• (Or web pages in a ~yourname/ subdirectory of our domain if you don’t have a personal domain)
• Email for your domain, forwarded elsewhere or readable with pop/imap/web
• (Or email for yourname@ourdomain if you don’t have a personal domain)
• Shell access (SSH access) including pine, screen, tf, whatever
• Future expansion may include: custom scripts, MySql database tables, java servlets, mailing lists, forums, whatever. Ask us.

Design goals

• Concentrate on the basics: DNS, Web and Email should be solid and done right. Other services may be flaky but the core should be solid.
• Off-the-shelf: Use well-known parts, preferably free. Avoid customization; too much customization makes us resistant to change. Components (software and hardware) should be easy to service, upgrade, or replace.
• Make things fault-tolerant: If multiple servers are available, have at least two servers able to serve DNS, web or email. Synchronize files between the servers at least daily, maybe hourly if resources permit.
• “Good enough” really is good enough: Don’t use creative, complicated or expensive solutions if there is a simple, cheap or free solution. Save creative solutions for difficult problems.

CasualNet 1.0: Initial design overview

Master server

• Keeps web data and various config files, pushes them out to slave nodes.
• Primary location for uploading/altering web data
• Primary configuration point for adding new domains
• Primary configuration point for email redirects
• Master is able to push data and configs to slave nodes
• Not a service point for normal web requests or normail emails
• (Can serve as a web or email server in emergencies, short-term only)
• May be at a dynamic IP address
• May be on a slow connection (but unmetered)

Primary slave server

• Software is installed with package manager (rpm, apt-get, etc)
• Don’t edit config files – they should be pushed from the master
• Primary service point for web requests (www.mydomain.com)
• Primary service point for web scripts, or anything with CGI data or session-based (cgi.mydomain.com)
• Primary service point for email (incoming, forwarding, or reading with web/pop/imap) (e.g. webmail.mydomain.com, pop.mydomain.com, smtp.mydomain.com)
• Users may have shell access for reading mail, but should not edit web files directly (this is a true “slave” for web content)
• Should be at a static IP
• Should have fast connection (DSL or better)

Secondary slave server

• Software is installed with package manager (rpm, apt-get, etc)
• Don’t edit config files – they should be pushed from the master
• Can also be a primary service point for web requests/static pages (www.mydomain.com)
• Standby/secondary service point for web scripts, or anything with CGI data or session-based (www2.mydomain.com)
• CGI data may be unique on the secondary, or may be pushed from primary to secondary.
• Standby/secondary service point for email (e.g. webmail2.mydomain.com, pop2.mydomain.com, smtp2.mydomain.com)
• Users may have shell access for “backup reading” of mail (see below), but should not edit web files directly (this is a true “slave” for web content)
• Should be at a static IP
• Should have fast connection (DSL or better)

In case of “Master server” failure

• User is not able to push new web content
• New domains cannot be added. Config changes cannot be made.
• Impact to email, web surfing, CGI etc should be minimal.

In case of “Primary slave server” failure

• DNS should automatically update to send web and email requests to Secondary slave
• Web users should see no change in www.mydomain.com
• CGI scripts will work, but may lose any saved state info (or revert to last sync if available)
• Email forwarding should still work fine
• If email is not forwarded, user will experience an interruption of mail reading service
• Users may manually change to the backup mail, but info there may be stale. (For example, secondary may contain an exact copy of email folders as of last night, plus any new messages received today, which will appear “new” even if the user read and deleted the message on the primary)