[NCUC E-team] Hosting the NCUC E-Platform

[Tapani Tarvainen]

On Mar 05 20:48, Tapani Tarvainen (ncuc at tapani.tarvainen.info) wrote:

> Is everybody happy with ssh & RSA?

> Show of hands: who uses git regularly enough to remember
> not only how to use it but also to actually use even when drunk? :-)

Should I interpret the silence that only I and David are comfortable
with either, or is everyone else just too busy to respond?

Anyway, I don't see any sensible alternative to ssh, but
git we can do without - as I said, I'd want a setup where
any random moderately experienced Linux admin can step in
without having to learn new tools in a hurry.

So, unless I hear voices supporting git soon, I suggest we go with this:

> for config files I think we could make do with just
> emacs backups (using its version control and "indefinite"
> number of backups in a dedicated directory).
> (If there're heretics among us who don't like emacs, I've got
> a little hack to make vim, nano and whatnot use same backup scheme.)

The hack mentioned with most editors as long as files
are opened from the command line ("vim file" instead
of just vim and then opening the file from within).
So it should be easy enough for any Linux admin.
(If someone likes doing inline editing with sed or the like,
they can save commands used in cut'n'pasteable form...)

On Mar 06 14:21, David Cake (davecake at gmail.com) wrote:

> 	Sorry, I am indeed an editor protestant, and I don't use
> emacs. I use vim when I have to, but my preferred editing option is,
> being an old-school Mac guy, editing documents remotely in BBEdit
> via SFTP - and I can integrate that with version control, or command
> line hacks if I have to, but not usefully with editor macros.

Eek, we've got a Mac user in our midst. :-P

But making even that horror work with emacs-style backups
should be doable, you just need to be able to run a custom
command (script) before and after opening the file.

Other issues:

* OS: I think we've agreed to use Ubuntu 12.04 LTS,
I guess 64-bit version (doesn't matter much now but we
might want to grow memory above 4GB some day).

* Initial disk partioning - since enlarging is easy but
shrinking isn't, start with something like 10GB system
disk and another 10GB backup and either enlarge them or
add other disks later as needed.

* We also need an internal name for the machine and the disks -
if someone has cute ideas let's hear them, otherwise
I'd just call the machine "ncuc1" and the disks
something like "ncuc1-root" and "ncuc1-backup".
(Anticipating the possibility that we might
want to get another machine later.)

That should be enough to get us started.

-- 
Tapani Tarvainen