|
Grex > Coop > #248: Running Grex as a VPS | |
|
| Author |
Message |
| 25 new of 56 responses total. |
bellstar
|
|
response 8 of 56:
| 
Dec 3 18:27 UTC 2008 |
And "administer" Grex using cpanel... argh...
|
bellstar
|
|
response 9 of 56:
|
Dec 3 18:29 UTC 2008 |
What becomes of Grex-damashii, then?
|
madmike
|
|
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. ;-)
|
slynne
|
|
response 11 of 56:
|
Dec 3 20:39 UTC 2008 |
It seems to me that a more likely problem would be that vandals on Grex
screw up things for our neighbors on a virtual machine. It would suck to
get everything all set up only to have a provider decided we aren t
worth the bother and kick us off.
|
cross
|
|
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.
|
tsty
|
|
response 13 of 56:
|
Dec 7 20:05 UTC 2008 |
hmmmm, interesersting remmzz ... how woudl they react to teh two
signarure factors of grex.
oper newuser
unix experimentation?
remmz... is it possile for your site to (ummm) 'test' the newuwer
adn compilerer optons that we offer here? ... just fo e kikx-n-grims?
|
klatta
|
|
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?
|
cross
|
|
response 15 of 56:
|
Dec 11 02:14 UTC 2008 |
Yes.
|
remmers
|
|
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)?
|
cross
|
|
response 17 of 56:
|
Dec 13 15:36 UTC 2008 |
I'm not opposed to changing, but it's a matter of having someone
do the work. That and convincing all the interested parties that
it's worth doing. As I said, neither of those are impossible tasks,
but they are *tasks*. If we wanted to switch, they would have to
be done. Of course, if we upgrade our current hardware, that would
have to be done as well. So really, nothing's free.
My own personal opinion is that right now, the VPS route isn't worth
it. We'd just about break even financially, lose some flexibility,
and hopefully gain some reliability. It would require a non-trivial
amount of effort to port the software and switch operating systems,
migrate the data, etc. Dialin would be an issue (and one which no
one has addressed yet). Staff time is an issue (I just transitioned
off of active duty and am in the process of transitioning back to
my day job; my time is severely constricted. I think most of staff
is in the same boat). The reliability isn't an issue so much right
now, regardless.
The virtual hosting thing should be something that we keep a close
eye on moving forward, but my sense is that we need to wait at least
a couple of years for (a) dialin to finally be a non-issue, and (b)
for the offerings in the space to mature a bit. My strong suspicion
is that we should do at least one more iteration of Grex on our own
hardware, this time not penny-pinching about things like hardware
RAID.
I argued strongly for FreeBSD on the current Grex hardware, but
lost that fight. Marcus and Steve really, really wanted OpenBSD
and no one else much cared either way. We can revisit it now, if
folks want to; there would be advantages to moving, and some
disadavantages (mainly involving the effort required to switch),
but is that a good use of limited resources at the moment? I'm
asking here; I really don't know. My sense is that there are more
pressing things (one of which is getting some more staff blood
involved with Grex).
|
remmers
|
|
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.
|
mickeyd
|
|
response 19 of 56:
|
Dec 13 22:50 UTC 2008 |
I was under the impression you could just map the serial port for the modem
to the VM.
Here is a link to using serial ports with VMware.. not sure if it is at all
helpful, but... i thought i would throw it in
http://www.vmware.com/support/ws55/doc/ws_devices_serial.html
|
cross
|
|
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?
|
tsty
|
|
response 21 of 56:
|
Dec 18 05:44 UTC 2008 |
ummmmmmm, can we users login with newuser? url pse?
|
mickeyd
|
|
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.
|
cross
|
|
response 23 of 56:
|
Dec 18 21:47 UTC 2008 |
I'm not opposed to doing that.
|
tsty
|
|
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.
|
jep
|
|
response 25 of 56:
|
Dec 19 15:00 UTC 2008 |
A JOA between M-Net and Grex?
There would be little reason at that point not to simply merge the two
systems. Both have Boards which do little and need to do little; a
shortage of staff members; and nearly identical conferencing systems
with mostly the same users. There is one staff member in common with
the two, who is cross. In a lot of ways it is already hard to tell
which system you're on. There could be a general and an agora
conference, with a few specialty conferences shared by both.
The difference between running the two organizations on one computer,
and running one organization, is minimal.
I do think we are heading in that direction. I've thought so for
several years. I think there are a few who would be vehemently opposed,
a few who would quit using whichever system they use now and go away
entirely, and the rest (a pretty small number) would go along with it.
|
cross
|
|
response 26 of 56:
|
Dec 19 18:44 UTC 2008 |
Eh, diversity is good. But virtualizing the hardware and running both systems
on the same physical box might not be a bad idea.
|
jep
|
|
response 27 of 56:
|
Dec 19 20:56 UTC 2008 |
I dunno, when it's the same group of users, I don't see that there's
much more diversity from two systems than from one. The world has a lot
of diversity in discussion forums, anyway. Grex and M-Net have very
little influence on that, whether each or both continue to exist.
|
remmers
|
|
response 28 of 56:
|
Dec 21 17:03 UTC 2008 |
Re resp:25 - "The difference between running the two organizations on
one computer, and running one organization, is minimal."
Wrong, if each runs in its own VPS.
But the question of a Grex/Arbornet merger is material for a different
item. For now I'll just say that I agree with the first sentence of
Dan's resp:26.
Re an earlier question: No, not interested in returning to staff at
this point, at least not the day-to-day-keeping-things-running variety
of staff work. Did it for 15 years; that's enough for the forseeable
future, for me. I'd consider lending a hand for projects of limited
duration where I feel I could be of help, such as migrating Grex to
FreeBSD, if folks should decide they want to go in that direction.
|
cross
|
|
response 29 of 56:
|
Dec 21 17:59 UTC 2008 |
Fair enough.
|
lar
|
|
response 30 of 56:
|
Dec 21 18:51 UTC 2008 |
you can forget about any grex/arbornet merger
|
jep
|
|
response 31 of 56:
|
Dec 21 21:40 UTC 2008 |
I wasn't proposing one. I was forecasting that that could happen someday.
|
tsty
|
|
response 32 of 56:
|
Dec 26 14:42 UTC 2008 |
having the wequivant of 'off site backup' grex<==>m-b0x creates a
more reliable 'place to go' - not too likely tat both b0xes, in different
placers, would be broken at the same time.
|