response 2 of 56:

Dec 2 17:20 UTC 2008

I agree. 

response 4 of 56:

Dec 2 20:59 UTC 2008

Actually, I think the "high end" package is slightly *more* than
what we currently pay at Provide.net (we pay $100/mo for colo).

Going virtual would mean porting the OpenBSD specific parts of
Grex's software investment to FreeBSD.  I'm fine with that (I think
we should have gone with FreeBSD instead of OpenBSD to begin with,
but lost that battle), but some other folks might not be.  Steve,
for instance, is a really big fan of OpenBSD and might not want to
switch.  It would not be *nearly* as big a deal as the move from
SunOS to OpenBSD was, but it is something to bear in mind.  It also
likely means giving up our dialin lines.  Again, I'm fine with that,
but I think it's likely going to meet stiff opposition from a few
diehard users of that service.

On the other hand, these things aren't insurmountable; after all,
most of the software we use is open source, meaning we can move it
around very easily (the only exception is Picospan, which we're
going to have to bite the bullet and say goodbye to sometime over
the next year anyway).  And it may be possible to rig up something
for a dialin solution (maybe a terminal server in somebody's house
configured to host modems and automagically SSH into Grex or
something.  Then you have to factor in the risk that this hosting
company might go out of business or change its pricing structure
or something of the like.  In these economic times, that's a
non-trivial amount of risk to assume.  Not a show-stopper, but
again, something to think about.  Finally, is what Grex does, with
providing access to a lot of services to nearly complete strangers,
really something that is going to be inline with this hosting
company's AUP?  That needs to be researched and settled; we've had
some problems with unruly Grex users causing problems for Provide,
and I can imagine that the problem would be worse in a virtual
context where our workload is competing for resources with those
of other paying customers.

The reason I'm guessing that Remmers believes this would be cheaper
is because, as I understand it, our *total* outlay per month is
about $150.  That includes $100 for colocation and another $50 or
so for the two phone lines.  If we went with this hosted solution,
and kept dialin access, costs would increase to around $170.00 plus
electricity and hosting for the modems and a terminal server.  I'm
guessing we'd end up spending around $200/mo, when you factor in
the cost of getting and maintaining a terminal server locally.

There are certain advantages with going with a virtualized solution,
but I'm not sure the problems we've had with Grex in the past are
among them.  The hardware problems we've had have largely worked
themselves out, and now that we've figured out the dance with calling
provide and getting them to reboot the machine if it crashes,
physical access is much less of a problem.  Before, we were much
more hesitant to do that since we thought we might be able to get
good information from the console about *why* Grex was down.  Almost
universally, we didn't do that, or what information we *did* get
was just the soft of thing that enabled us to say, "yup, there's a
bug in OpenBSD.  It's known and they're working on it."  It wasn't
very *useful* information, so now we've more or less given up on
that and just say, "screw it; reboot it and if there's anything
useful it'll be in the logs or the crash dump anyway."  Further,
recent security problems with virtualization servers make me wary
of wanting to host a service like Grex somewhere where other
organizations can have root on the same *physical* hardware.

On the other hand, it's getting about time that we got a new machine.
That's going to cost about $2500 or so.  That's equivalent to the
extra money we'd spend over a little over four years of virtual
hosting, and that's about how long we could expect to have that
machine before it was time to upgrade again.  So I'd guess that
financially, we'd about break even.

I do think there's a place for virtualization on Grex, but it has
a lot more to do with partitioning services and seemless upgrades
than cutting cost or boosting reliability.  For instance, we may
want to push email *processing* to a different "host", and it would
make upgrades really, really nice if we could "clone" Grex, upgrade
the clone, *test it*, and then "shift" the references to user data
directories in a virtual machine and bring up a new, fully tested,
upgraded Grex with a single reboot.  But that is *not* what I gather
this service is offering.

response 6 of 56:

Dec 3 18:11 UTC 2008

I wonder if it might be possible to get temporary access to a 2nd
virtual machine at a reduced cost for purposes of testing an upgrade? 
Maybe Grex could buy access to a 2nd virtual machine permanently,
perhaps with limited access and a reduced cost, so the staff would have
a sandbox for testing.  This surely is not a unique need for Grex.

I regard a move away from physical hardware to be a beneficial one for
Grex.  A virtual machine will never wear out or become outdated.  We're
a virtual community anyway and don't need physical hardware for any
purpose as far as the community is concerned.  Is a professionally
administered virtual machine really going to be less secure than what we
have now?

I wonder if we couldn't buy access to an inbound dial-up ISP account and
distribute it for use by anyone who wants to use it for less than we
currently spend on a phone line.  I suppose that would run us the risk
of someone making it their own permanently.  It seems to me there ought
to be some solution like that which is much cheaper for us than
maintaining a terminal server with Internet access and a couple of phone
lines running to it.

response 8 of 56:

Dec 3 18:27 UTC 2008

And "administer" Grex using cpanel... argh...

response 10 of 56:

Dec 3 19:45 UTC 2008

A "virtual machine" is _still_ a machine. 

I would be leery of sharing a processor. 

as cross indicated in resp:4 
>we've had some problems with unruly Grex users causing problems for 
>Provide, and I can imagine that the problem would be worse in a 
>virtual context where our workload is competing for resources with 
>those of other paying customers.

Likewise system bogging by our 'virtual neighbors' could bring GREX to 
a crawl in spite of all efforts to restrict foul play. All it takes is 
a badly written SQL query to lock up a shared CPU then somebody will 
still have to call somebody for a reboot.

Imagine the thrill of getting root on the mothership - the cracking of 
that 'virtual devide' - tell me that ain't going to be happening. ;-)

response 12 of 56:

Dec 4 03:45 UTC 2008

resp:5 Did you read resp:4?

resp:6 Maybe, but that needs to be investigated.  My suspicion is not; this
is the new version of what services like rackspace used to do; sell you a
machine in colo, the hardware maintained by them, but you run whatever you
want on it.  It's a specification of "the cloud."  And it's a nice idea, as
long as your provider doesn't go out of business.

I think the idea of getting ISP access for our users isn't a bad one.  That
would be pretty interesting, and might save us some dough.

resp:10 Part of the problem with virtualization is that bugs have recently
been discovered in both Xen and VMware (and presumably other virtualization
packages) that allow root on a virtual host to leverage its way to root on
the physical host.  From there, all the other virtual machines are toast. 
That's a lot of risk to assume.

resp:11 Darn skippy!  I doubt mostof these hosting services are ready for
what Grex does.

response 14 of 56:

Dec 9 06:10 UTC 2008

It is nice to see that cloud offerings have matured enough to make this
viable. 
Is there any greater liability for the operation (such as oper newuser
and experimentation) when you are "embedded" as it were into their
hardware? 

response 16 of 56:

Dec 12 18:10 UTC 2008

Re resp:14 - Hi Ken!  Long time no see!!

Re the OS - I'd be fine with switching from OpenBSD to FreeBSD.
It's something to consider, even if Grex continues to run on its
own hardware.  I have the impression that FreeBSD has a much larger
installed base and user community than OpenBSD, an important consider-
ation when it comes to support.  Porting Grex software would
undoubtedly be possible and would probably be pretty easy.  Users
wouldn't notice much difference.  Hey, M-Net runs on FreeBSD.  And I
suspect that the security advantages of OpenBSD are largely illusory,
at least for a service like Grex.  Historically, can't most of our
security issues be traced to the fact that we've been running an 
open newuser with immediate Unix shell access?

Re resp:7, resp:8, and resp:9 - Bellstar, I'm not advocating
anything of the sort.  The user interface under a FreeBSD VPS would be the same
 as it is now.

Regarding going the VPS route - It still seems to me that making the
hardware somebody else's problem, not our problem, would be a big win
for us.  I think Dan's right that the service I've been playing
around with (rootbsd.net) doesn't offer the kind of flexibility
we might want (e.g. cloning).  On the other hand, something like
Amazon's EC2 service does - you can create and delete machine images 
by typing a few commands, shift an IP address from one virtual
machine to another, etc.  

On the other other hand, EC2 doesn't offer FreeBSD yet, although I 
believe it's being worked on.

Security issues with Xen and other virtualization technologies - well,
I'll have to plead ignorance there.  That issue would have to be  
looked at carefully, of course.  Any references you can cite on
the recently discovered bugs that allow root breakins on the 
physical host (re resp:12)?

In looking around, I've found tons of VPS hosting services that offer
Linux, rather few that offer FreeBSD, none that offer OpenBSD.  The
rootbsd.net service that I've been using is the only one I've found
that offers FreeBSD at a price that Grex could afford, although this
situation may change in the future.

After playing around with FreeBSD for a few months I must say I
like it a lot as a server environment, so I'd be delighted to see
Grex run it too.  But given that Linux seems to more widely supported,
I'll raise another question:  Would there be advantages to running
Grex on some Linux flavor (e.g. Ubuntu or CentOS)?

response 18 of 56:

Dec 13 16:33 UTC 2008

Well, I've already ported party and Jan's write/tel to FreeBSD
(actually, the latter is an official FreeBSD port) and have started
looking into installing Backtalk/Fronttalk as well.  As mentioned in #0,
I've also installed and configured Apache, MySQL, PHP, and Postfix on my
FreeBSD system.  They all work pretty well too! :)

So I'm getting some familiarity with FreeBSD system administration and
would certainly be willing to pitch in and help should folks decide to
go the FreeBSD route.

response 20 of 56:

Dec 14 15:48 UTC 2008

resp:18 Are you saying you'd like to rejoin staff?  'cause we could use the
help.  But quite a bit has changed since you left.

resp:19 No, the issue here is where to physically put the modems.  In the
case of what remmers is proposing, the entire machine would be virtualized; we
wouldn't even really know where the hardware was.  And if that's the case, then
where do you put the modems?

response 22 of 56:

Dec 18 20:48 UTC 2008

re #20 - thanks.
 
 What if we virtualized grex and m-net on the same hardware? like a two in
one type system? just kinda merge them together, but keeping them seperate?

Ok, i'll shut up now.

response 24 of 56:

Dec 19 09:56 UTC 2008

oh, wow ... the word 'merge' is anathema in extremis.
  
not even teh det freepress & det newds is as bad a thought. 
  
but a thought nonetherlwess..   
  
and it;s not an hostility thing .. it's a2 cultural.