Well I have been doing some thinking about what my next semester’s
Capstone Senior Software Project should be and I just came up with it
about 5 minutes ago. From my searches on the net for a Linux lab
management software there is very limited or no software. About the
closest thing that I have seen is the K12Linux (www.k12linux.org), which
is good software but it is not too usefully if you are not running it in
a high school lab or some really dorked up lab where students need only
a browser and nothing else. Although I find the idea of webalizing the
entire desktop thats not what k12linux does. The idea behind it is thin
clients…
Now, what I am thinking about is:
a) A customized Slackware linux made specifically for a college lab
(this means that it needs everything from compilers to crazy software
for doing forensics work), centralized around a single desktop
environment (kde) and as a second option a window manger (fluxbox, xfce,
haven’t decided on this one but I am leaning towards xfce).
b) Create a floppy sized distro which does nothing else but run a
Ghost like daemon which sits and waits for an image to come in. This is
almost done, since g4u exists. It will have to be modified to only do
image dumping.
c) Modify the the Slackware install to have three different setups:
i) Lab Machine - create a floppy sized partition which will
house the g4u boot up(non customizable). Create a small swap partition
of 128 mb (customizable), create a / partition using the rest of the
space, (optional) create a /work partition (if this option is used then
automatically readjust the / partition to release the space specified
for /work). As safety net, create a check that will make sure that if
you have a small hdd you cannot give less than 3gb of space to / since
it will be a relatively big install.
ii) Work Station - basically the same as the Lab Machine setup
with the exception of the g4u partition since we will not manage images
for office machines.
iii) Normal Slackware install. This will basically be the
unmodified slackware install, for those cases when you do not need the
other two options, or its some special case. This option will not really
be needed for lab management but it will be a nice thing to have so you
do not have to have 5 different cds of slackware laying around when you
can have only one :).
d) For the Ghost side of things. Create two servers one which will
run when g4u runs so an image can be pushed to all the machines
remotely. Second on which runs when the machine is running normally.
This daemon will listen for remote commands from the administrator,
setup the machine to be imaged: Now, since we do not want everyone to
know about the “secret” g4u partition that means that when the daemon
detects a request for an image push it will replace the existing
lilo.conf with one that only has the g4u boot option so we can boot into
it only. When we are done it imaging the daemon running on the g4u side
will detect the done state and put the old lilo.conf file back so we
will only have the normal Slackware boot again. (this might sound a bit
messy but it is the only way I can think of doing it as of the moment).
e) The daemon running when the machine is not in imaging mode will
also be used to take care of mass package installation of things that do
not like running off a networked share (A great example is OpenOffice).
Those packages need to be installed locally. Also, it will take care of
machine clean up: clean up /work occasionally, clean out /tmp, etc.
f) Finally create a client. I have been debating about this one. I
do not know if I want to make it using Java so it will be usable on any
platform or if I want to make a Java client for Windows and OS X and
make a Qt/KDE one for Linux. So far I am leaning towards the Java
approach since it will be a lot less work.
So once all of the above is finished an administrator would only have to
either:
a) run the Lab Machine install on once on each machine he will be
dealing with.
b) run the floppy distro which will run in daemon mode and then go
and push the image out.
Either approach will take a little time the first time it is done but
after that should be just the matter of selecting the image needed to be
pushed out and telling the client to push it out.
Thats it. Of course this is in no way finished since there are still the
protective parts that need to be taken care of (machines being alive,
machines dying in mid imaging, etc). If you have any suggestions please
feel free to comment and add.
Post a Comment