[sf-lug] Fwd: [PenLUG] Donation for hosting

jim stockford jim at well.com
Mon Oct 23 09:02:10 PDT 2006


very helpful instructions below, thanks.

On Oct 23, 2006, at 2:22 AM, Rick Moen wrote:

> Quoting ron (rondosxx at yahoo.com):
>
>> I am totally unaware of how even our own LUG covers its operating
>> costs. I suspect they are minimal, though perhaps a couple of people
>> are supporting it under the radar; Jim and Rick come to mind.
>
> Jim Stockford picks up the only direct cost I'm aware of, which is the
> approximately $12-15 per year for domain registration (used for the Web
> site).  The SF-LUG mailing list shares my cheap ol' Linux server on my
> house aDSL line.  That doesn't per-se cost me a penny, because I keep
> that server up and running for other reasons, the mailing list adds
> negligible extra load to what the host already does, and y'all are
> perfectly welcome guests.
>
> I cannot comment on PenLUG matters, but the general topic reminds me of
> something I've been pondering for a while:
>
> Typical Web/e-mail sites (Internet servers) for LUGs or similar small
> non-profits or small businesses can run perfectly on throwaway-hardware
> Linux servers drawing ridiculously small amounts of bandwidth.  Here's 
> a
> quick'n'dirty way of guesstimating bandwidth requirements.
>
> 1.  Run "/sbin/ifconfig [interface]" to get the transmitted (TX) and
> received (RX) byte counts.  Note down the time/date.
>
>  $ /sbin/ifconfig eth1
>  eth1      Link encap:Ethernet  HWaddr 00:D0:B7:93:31:0E
>            inet addr:198.144.195.186  Bcast:198.144.195.191 
> Mask:255.255.255.248
>            UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>            RX packets:66321724 errors:0 dropped:0 overruns:0 frame:0
>            TX packets:77788011 errors:0 dropped:0 overruns:0 carrier:0
>            collisions:0 txqueuelen:1000
>            RX bytes:1500480318 (1.3 GiB)  TX bytes:903698173 (861.8 
> MiB)
>            Interrupt:11 Base address:0x1080 Memory:fa202000-fa202038
>
>  $ date
>  Mon Oct 23 00:13:41 PDT 2006
>
> 2.  Wait a while -- preferably at least a day.  Do step #1 again (to 
> get
> a second data point at a later date/time).  Subtract figures between 
> the
> dates, to get bytes received and transmitted during the period in
> question.  Add the TX and RX byte differences together.  (They're both
> traffic.)  Divide by elapsed time, to get average network traffic per
> unit of time.
>
>
> Traffic levels may have spikes, but typically not significant ones for
> small groups' Internet sites' Web and mailing list traffic.  Over at
> SVLUG, one of the largest LUGs in the world, we did this for our
> "www.svlug.org" AKA "lists.svlug.org" AKA "svlug.org" host, and found
> that average traffic levels were so low that we could have comfortably
> put the machine on a dial-up modem line, and not suffered any 
> noticeable
> bandwidth shortage.
>
> So, what does such a site really need, if not non-trivial bandwidth?
>
> o  IP service that works, at one or a series of locations.
> o  one or more cheap throwaway machine (PII, 128MB RAM, etc.)
> o  backups
> o  ability to re-point DNS records fairly quickly (1/2 day, say)
> o  system administration at the level of an interested and careful 
> amateur
>
> A friend of mine runs a set of interrelated domains hosting Web sites
> and mailing lists for some large, annual volunteer events -- which were
> for a long time hosted on one of the volunteers' Solaris machines.
> (For any who don't know, Solaris is a Unix, recently open-sourced.)
> That machine lived at the volunteer's house, which was on PacBell/SBC
> home aDSL line.  Recently, in a development that will be familiar to
> frequent SBC broadband customers, the volunteer has been suddenly
> subjected to weeks of mysterious service outage, with no end in sight.
> My friend is livid, but unfortunately for him had no Plan B, and so is
> currently stewing over the situation.
>
> What went wrong?  a) There was no standby spare machine or even standby
> spare hard drive.  b) There were no offsite regular backups.  c) Nobody
> in the group had the expertise to make use of those things, had they
> existed, anyway.
>
> Despite the fact that building a replacement server (with Linux, BSD, 
> or
> Solaris) and deploying it any-old-where is dead simple, my friend is
> still suffering extended downtime while looking for a "hosting service"
> to magically take care of all backup, maintenance, and system
> administration for him, for some serious bunch of money per month.
>
> The way I'd do it is:  Run the Internet services on a cheap machine
> running just about anywhere that provides a static IP.  (Avoiding
> PacBell/SBC broadband would be common sense, though.)  Have daily or
> better backups.  Have at least one standby machine available, 
> preferably
> OS-loaded and ready to go.  (Making the backup be directly onto one of
> the spare machines would be a nice touch.)  Be able to re-point the DNS
> in a hurry.
>
> Not a lot of expertise is needed, frankly, and rudiments of Unix system
> administration aren't exactly brain surgery.  (Dealing effectively with
> the spam problem's about the only challenging part.)  Yet, people spend
> a lot of money and time on paid hosting arrangements, colos, etc., when
> most of the time they don't have to.
>
>
> _______________________________________________
> sf-lug mailing list
> sf-lug at linuxmafia.com
> http://linuxmafia.com/mailman/listinfo/sf-lug
>





More information about the sf-lug mailing list