Note: I marked items with "==>" that require a serious discussion before we jump on this bandwagon.
I called OLM and talked to the sales people for a while, asking questions we discussed and some more that came up while I perused their demo pages. The sales woman passed me to technical support to answer a few she and I noted were beyond her knowledge. I talked to the tech support guy for a while, then talked to both his supervisor and a "senior tech" about various things.
Except for my initial confusion about how they implemented their virtual server, which their senior tech cleared up somewhat for me, it is exactly as I thought.
To use their VPS requires that we take over sysadmin of a Linux system (a modified version of Red Hat 7.2). That it happens to be a piece of a larger system is irrelevant -- what we see is a standalone Linux system sitting directly on the Internet. This is the biggest thing we have to decide. I know a lot about this type of system. Several other people know enough about Linux or Unix systems in general to manage pieces of it.
==> Do we have the combined expertise and the combined "free" time to manage this? Note: If we ever expand to a dedicated server, they will do less than with the VPS.
My answer to that question is: maybe. If we do take on this kind of system, I would insist on a very limited set of people with root access, with any use of "root" discussed beforehand. DNS management and mailing list management are done through a GUI, which requires authentication, but doesn't require raw root access.
Details of interest: [[These are their answers to questions, with a little of my analysis. There is no way to know all the technical details until we use it.]]
They are running a Linux that is a couple years old. It will be upgraded when Ensim upgrades its custom virtual server patches to the Linux kernel. There's no schedule for such an upgrade.
The basic cost for the 2Gig-of-disk, 256Meg-of-memory VPS-1 is $69.95 per month.
The use of BIND, adds $20 per month. I'm not sure why it costs more.
With BIND we would be able to set up primary or secondary domains anywhere we want.
They back up everything in /etc, /var and /home weekly. We can get files back from those areas individually or in bulk after a disk crash. The rest of the system normally does not change and would be restored after a crash to their original states. If we change something in /usr/local or /usr/lib or . . ., we'd have to back up and restore it ourselves. This is not hard. They have a setup to take backups over the net to another host.
They have a site firewall that blocks only the IRC ports. We would have to handle our own security. If left to me, I would create a master site somewhere else and upload it to the external site. If that isn't workable for the group, then we'd have to set up a firewall.
On RedHat 7.2, we'd have to use a feature called "ipchains". In later revs of Linux, a much better system called "iptables" is used.
I have done this -- it is seriously ugly but only has to be done once. I would initially install a firewall that only allowed access through SSH, FTP, SMTP (mail) and HTTP (web). Then we'd argue about anything else. Under no circumstances will any disk-mounting protocols be allowed (CIFS/SMB/Samba, Netbios, NFS, AFS, etc.)
Anything we don't change in the system areas will be maintained by OLM. So we can ask them to apply the latest Apache, sendmail, FTP server and SSH security patches.
==> Someone must be responsible for keeping track of the "announce" mailing lists for each of the software packages that handle a protocol we allow through the firewall.
Majordomo, mailman and other mailing list managers would have to be maintained solely by us.
They allow FrontPage extensions, but they do not mix with FTP access.
This is tricky. A web "site" is a single directory tree where files reside. Web servers connected to one or more web addresses (like www.nesfa.org or www.nesfa.com) from one or more "domains" (nesfa.org and nesfa.com respectively) may point to the same "site".
A "site" may either use FrontPage extensions or FTP access, but not both. The use of FTP obliterates pieces of the FrontPage extensions setup forcing a reinstallation of the FrontPage extensions software.
Now you know why the N4 site on OLM loses its FrontPage extensions.
The reason I am careful about "FrontPage extensions" is that FrontPage can be configure to use FTP instead of its fragile and proprietary MicroSquish protocol. So "FrontPage" is a formatter that can copy files via one of two protocols. "FTP" is a protocol that says nothing about how the page was created. "FrontPage" and "FTP" are not opposites; "FrontPage extensions" and "FTP" are.
==> FrontPage and FTP don't mix. We can discuss this. It not reasonable to force everyone to use FrontPage. I don't see us splitting the domains and assigning one to FrontPage and the other to FTP. I believe we should proceed this way:
Test using FrontPage in FTP mode -- now. (on the OLM system we have)
If that doesn't work, call OLM again and find out if we can simply reinstall FrontPage every day in an automated way. (Not difficult to automate if it is possible at all.)
If that isn't possible -- I have a couple ideas, but no time to write them out. That's mainly why this is marked "==>"
The message I asked Tim S. to send me at the Wednesday meeting contained these questions, so I thought I'd try to answer them as I believe they answered me:
Do we have full control over DNS?
Who does software updates? Who does security patches?
Both questions have the same answer:
They do, for anything that we haven't changed.
We do otherwise.
Who and how is the firewall(s) maintained?
Except for IRC filtering (done by the OLM site), firewalls are software and entirely under our control.
I didn't ask this specifically. Their demo pages have a "statistics" reporting page, which will give us some info.