[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [K12OSN] teaching kids sys admin with VM's





Robert Arkiletian wrote:
On Jan 17, 2008 6:11 PM, James P. Kinney III
<jkinney localnetsolutions com> wrote:
I can see many, MANY issues with this setup. Not the least of which is
kids with root access AT ALL on a networked machine.

What's the worst thing you could do if you were a cracker student in
the environment that I described to Les?

An idea is to skip the installation part and provide vmware-player
images for them to admin. This way you can lock down the configs (until
they figure out how to change things) and can provide scenarios for them
to look at/tweak/setup/fix, etc. Vmware-player is free and lighter
weight than full VMWare desktop.

I'm not scared of them messing up their config files. So they bork
their OS beyond repair. They just delete the VM and start again. It
also defeats the purpose of having them learn how to setup raid and
everything else. I'm hoping I will be able to create multple virtual
HD so kids can learn how to setup a RAID system. Then stop the VM,
remove one of the drives and see the U_ in /proc/mdstat, then tell
them to add another drive and resync the mirror. That would be cool!!!

Server side is a challenge as each thin client will need RAM, plus the
server itself AND now each VM. With the player, you pre-set the RAM
size. However, if you use full VMWare, the students can change the RAM
size for a VM. That has the great potential for bringing down your
server hard and fast.

Hmm. This is a problem. I can't allow kids to choose how much actual
resources they give their VM's. I have to be able to set a limit on
the amount of ram, HD size they can allocate. Also I don't want them
to run more than one VM each. I think this might be more difficult
than I first thought.


How about this. You create a virtual machine for each student, and you own them. Create a bridged interface on the host machine for each virtual machine, and let the students ssh into them.

Positives: You control how much ram is allocated, and the students can't start/stop the virtual machines without your authorization. Negatives: Students will have to install the OS at your desk (or logged in to your account -- or a special account made just for this case) because you own the virtual machine. The virtual machines will also be visible to the local network (but possibly you could firewall them off so that the network won't be brought down by a rogue DHCP server).

I'd also like to recommend you try VirtualBox. I've been using it on Debian with great success. Its interface looks like VMware, but it was a quicker installation than VMware (last time I tried VMware, anyway). There is an open source version that is not crippled in any serious way. The debian package is virtualbox-ose.

-Rob

As for teaching an installation, the RedHat derivatives have the ability
to record an installation process as a flash movie file (or maybe that
was doing it over vnc - I forget). That is a GREAT documentation tool!!


No doubt, but nothing beats doing.

Since you have old PII's you could use those with old hard drives and
let them install there. A net install is fast but a CD install is
typical. When done, just unplug the hard drive again :)


No go. I have multiple blocks and don't want kids opening up real
hardware that has to work every period. In addition have you tried
installing a recent linux distro on a PII with 128MB of ram. :)

********************************************************

The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. If you are not the addressee, any disclosure, reproduction,
copying, distribution, or other dissemination or use of this transmission in
error please notify the sender immediately and then delete this e-mail.
E-mail transmission cannot be guaranteed to be secure or error free as
information could be intercepted, corrupted lost, destroyed, arrive late or
incomplete, or contain viruses.
The sender therefore does not accept liability for any errors or omissions
in the contents of this message which arise as a result of e-mail
transmission. If verification is required please request a hard copy
version.

********************************************************



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]