Slashdot Mirror
Syncing Options for Computer Lab Machines?
sirfunk asks: "I'm going to begin helping out maintaining the computer labs around my university campus. I was wondering what solutions the Slashdot community had hints and tips for maintaining computer lab networks. We need a solution where we can keep a remote image on a server, and the computers will update to that on bootup. We also need them to be able to update, even if Windows is severely messed up (so if Windows dies, just reboot it). I know there's commercial solutions like Deep Freeze, but I was hoping someone knew of a creative Open Source alternative. I'd love if we could run these as dumb terminals with *nix, however that won't be an option for the general public. One Idea I had was to make the machines boot into a Linux partition that would rsync a FAT filesystem (the update) and then reboot to that FAT filesystem. The whole thing about getting it to boot into Linux first and then Windows next might be tricky. I would love to hear everyone's ideas on this topic. If you have any ideas that would run cross-platform (Mac/Windows) that would be great, too."
For far less than the price of a real desktop, you can get a Windows Thin Client that will work and play well with your NT servers.
For a lab, you may even be able to get volume pricing.
If I understand the situation correctly then you want to re-image each machine on boot. I have looked at this and a complete XP Pro image on a Gb network takes anything from 20 - 45 mins. This is using a product called Altiris Deployment Server which uses PXE under the covers. If this is acceptable then I'm sure you could do your own PXE solution with a Linux DHCP and TFTP server. You can download a free 30 day eval to see how it works and "clone" the procedure.
I will not be pushed, filed, stamped, indexed, briefed, debriefed or numbered.....my life is my own.
When I worked in support (last gig was supporting internal classrooms) we used Altiris LabExpert. They've changed the name to Application Management, but this may be what you want. It's not open-source, but comparing this program's prices to the other similar ones on the market, we saved a TON of money (one vendor wanted nearly $150K for all the computers we were going to use this on. I think we spent $7K at each site for a total of $28K)
.EXEs, burn to CD and deliver that way.
It has a server and client modules. The clients sync with the server on reboot. If there are jobs in the queue, the server pushes the jobs, they're applied and rebooted.
To create jobs, you make a baseline of an OS, install the application, and then run the baseline app again. The application examines the entire disk as well as the registry and notes changes. You build a package containing just the changes.
You can even turn the packages into self-extracting
Cruising the internet on my TI-99/4A @ a whopping 300 baud!
It seems like you are pro-open-source, but don't dismiss the commercial products completely. Novell's ZENworks for Desktops (ZfD) product is quite simply amazing! It also happens to do exactly what you're talking about.
Does it require Novell servers? No, it does not. You can read more from the ZENworks documentation at Novell's website. Read the ZENworks 4 docs. ZENworks 6 is a bundle of ZENworks 4 for Desktops and ZENworks for Servers and ZENworks for Handhelds.
I once read about a university (I think in the UK) that managed 30,000 Windows desktops with only six people! Also, the largest companies on the planet tend to favor ZENworks for Desktops over SMS for deploying patches.
My computer support group uses ZfD to manage about 1,500 computers whose configurations vary widely from P2-400's to P4-3.06 Ghz boxes running anything from Win98 to WinXP. About 400 machines are in labs, but the rest are faculty or staff desktops. ZfD is extremely flexible. ZfD has an imaging solution, but is not limited to that.
ZfD imaging boots up a Linux agent first, either from the hard disk or by booting it over the network from the ZfD server or from a bootable CD-ROM. This agent checks Novell eDirectory to see what it should do (store an image of this workstation on the server, install an image onto the workstation, or other tasks). Once the image has been transferred, the computer reboots into Windows. Each time the computer boots, ZfD will check to see if it should perform an imaging task; if not, then it just boots Windows. ZfD can also add software to the base image on-the-fly!
Alternately, you can automate an install of Windows (just the base OS, with patches). Then install the ZfD agent and let it install all the other software for you. This solution is the ultimate in flexiblity, but requires you to have a pretty intimate knowledge of how Windows and ZENworks function, like what registry entries are dangerous to deploy to other workstations.
A combination of imaging and software deployment is an excellent way to get a workstation installed quickly and have a large selection of software available. You can deploy a small image (Windows, ZfD agent) and allow the ZfD agent to install other software as needed by the users. For example, ZfD can put items on the Start menu and when the user clicks on that item for the first time, ZfD installs the software. Rarely does one need to reboot.
ZENworks is probably the best solution available for managing large numbers of Windows desktops. It is powerful and flexible. Like many powerful tools, it is also a double-edged sword. It can easily deploy a patch and fix thousands of workstations, but if you deploy the wrong registry entry, you can just as easily break thousands of workstations. This is why you have to know Windows inside and out.
Finally, Novell has really good discounts for education. If you don't already have it available to you, check into it.
Ouch! The truth hurts!
Check out Unison. Not sure if it is exactly what you want, but it is a nice cross-platform filesystem sync tool I use.
/..sig file not found - permission denied.
Actually, how "close" are the images, network-wise? As another has noted, it will take a long time do the image.
In my labs we just deploy the machine and update the software remotely as needed. Sure, we should redeploy once or twice a year to clear out the cruft that builds up ove a semester. But I think it beats re-imaging on every boot.
A good question is how much are you imaging? That could save some time.
Of course, that's just my opinion I could be wrong.
You could always have a partition saved on the a 2nd hidden partition and recover from there. That would make it a LOT faster than trying to go through the network. The LG Internet fridge recovers it's win98 partition and resets itself by doing this. (No I don't have one - they're $8000.)
I don't know what tools they use for this though, but dd should work. This is also how some companies use to have the recovery information for their desktops. If you used your rescue CD, it would revover from that hidden partition.
Anyway, just a though...
-P
You can install rsync for windows, which is easily done using cygwin. Write a little shell script (since you're pro *nix) and set it up to run on boot. That oughtta be fairly easy.
:(
When I was working computer labs, my preferred solution was linux + vmware, BTW. The machines ran linux (with everything mounted read-only - I'd netboot if I did it again), started up X, and then fired up a VMWare instance that ran full screen. The virtual disk image was on a remote machine (though it could just as easily be pushed to the client machines when it was updated), and was opened read-only on the clients. If anything happened, they'd just "restart", which just threw away any local changes that they'd made. It was great for the net admin classes, as we could give the users full control of the windows machine without worry of them actually screwing anything up. Also, you can update the install at any time by simply opening the disk image with "save changes" enabled. If you set the file system permissions so that normal users can't write to the image even if they do manage to change the vmware settings, you're pretty well set.
Granted, it costs some money, but it works real well - if you don't need direct hardware access to devices not supported by the host OS. That's the VMWare solution's catch - not all hardware is perfectly supported by linux, and using Win32 as a host is rather pointless.
http://www.systemimager.org/
SystemImager makes it easy to do automated installs (clones), software distribution, content or data distribution, configuration changes, and operating system updates to your network of Linux machines. You can even update from one Linux release version to another!
It can also be used to ensure safe production deployments. By saving your current production image before updating to your new production image, you have a highly reliable contingency mechanism. If the new production enviroment is found to be flawed, simply roll-back to the last production image with a simple update command!
Some typical environments include: Internet server farms, database server farms, high performance clusters, computer labs, and corporate desktop environments.
You could... (in theory) clone your linux box with the windows partition intact, set your grub.conf to boot windows automatically postinstall. Whereby you update your 'gold image' and redeploy it with patches, etc. Rsync works on win32 but I'm not sure if daemon mode works, this could be alleviated by running a scheduler but alas you would have to script (not completely recommended for security purposes) the patches or software to run/install.
When I was an undergrad, we had machines that were managed like this.
There were two different setups, and I can't tell you what software they used to achieve them, but I can tell you what happened from a user's perspective.
In the first setup (a small lab -- about 20 machines), the machines were setup to automatically replace their installation of Windows once a week at a "convenient time". The problem was, this time was convenient for the sys admins, rather than the users. So, when working on a project out of scheduled lab times, I would often have to wait for about 30 mins to start work while the machine got a fresh copy of Windows. This was even worse if there was more than one person trying to use the machine, as the network would slow down.
The obvious solution to the above problem is to change the time to something like 3am. However, in these days of devastating Windows worms, I don't think it's an option to install a new image once a week. Also, many university computer facilities are open 24/7; you often get students who like to work antisocial hours, so choosing a convenient time is pretty difficult.
The second setup was a more campus-wide solution. I'm not sure how they achieved it, but it seemed that each machine maintained a log of which files were changed while a particular user was logged on. When they logged off, the machine simply returned the disk to the state it had been in before.
There are many problems with doing what you suggest:
+ User ignorance: naive users are used to saving their stuff to C:. If you then overwrite the disk, they will complain about your policy eating their homework.
+ If you have one 'master' disk image, how do you manage the different drivers required for different hardware? It's impossible to maintain a large number of systems with exactly the same hardware (when you consider component failures etc).
I would suggest the following: Use the permissions and management facilities of the OS to prevent users installing their own software or writing to the C: drive etc. Really lock them down. Give each user networked disk space which only they can write to. Make sure that you have an automated way to roll out patches, and keep on top of things. Make sure your virus protection is tip-top. Try to reduce the possibility of students infecting systems via removable media (I'd outlaw floppy disks, but students still use these!).
Further, for each "group" who need to work together (e.g. small groups of final year students who are working on a particularly project), provide a "transfer"area which they can all read and write. For users who need to install their own software (e.g. computer science researchers), establish a small team of sys admins at their location and let them do their own thing -- just make sure they are sufficiently safe behind a firewall so they can't easily shoot themselves in the foot and your managed main network is safe from any of their screw-ups.
"The noble art of losing face will one day save the human race"---Hans Blix
Set up Lilo with two targets: Linux and Winders.
Make Linux the default target to boot to.
When you're inside of Linux, and you want to set it so it boots Windows for the next boot, and only the next boot, then you do a
lilo -R windows ; shutdown -r now
The next boot will be into Windows. The boot after that will be back into Linux.
Seems like you could set things up very easily to do what you want.
If tits were wings it'd be flying around.
Right now, I have a "partimage" solution we use to reinstall our PC rooms (115 PC's right now) in a similar way to what's asked for in the originating post.
/dev/hda1 will happen (syslinux variant, PXELinux used, so changing the PXElinux configuration file for a certain MAC will do that trick)
Complete picture:
+ PC boots, loads linux from network (PXE boot)
+ Linux does an fdisk, start partimage and restores original image
Overnight reinstalls are necessary 'cause we want to give students total freedom on the machine
Two problems:
1) found no way to boot windows from a running Linux so far. Temporary solution is a reboot, having the DHCP server change it's PXE options OR alter the file that decides whether a Linux networkboot or
2) Partimaged, the serverside program that offers the images on the network, is pretty much crippled by its limitation to 10 (15 now?) simultaneous clients. This makes it impossible to update all PC's in a single room (up to 30) at once, even though the server capacity is up to it. Tried to run multiple instances of partimage on different listening ports, but this crashes partimaged...
Improvement would be a good thing here, so I'll be watching this thread closely.
Caveat Emptor: this message won't selfdestruct if you memorize it!
This probably won't be able to apply to you, but it's worth knowing: Mac OS X Server can do this out of the box (to Mac clients). Apple calls it "NetBoot", and it's been available since at least 2000; I believe the tech came from NeXT originally.
Under OS 9 and 10.3 it allows for clients-without-drives as they get all their OS etc from the server down the wire (10.1,
--
$tar -xvf
Is that too simplistic? man lilo for the -R switch.
I think, therefore thoughts exist. Ego is just an impression.
I helped a guy out set up this exact FAT32 + rsync setup.
We used Smart Boot Manager and set up scheduled reboots.
Works like a charm. Note that it not only cleans up the machines at the end of each day, it will also allow you to patch your master image and push that out to the network. (even a one-day lag is still faster than going from machine to machine patching or ghosting)
Watch out for oddities such as the Daylight to Standard time switch, though.
-transiit
We did such a thing to manage 3 computer labs for the college of engineering at a large university. (They deployed it to a couple more labs after I graduated). We used a program called PCRdist. (http://www.pyzzo.com/). It is based off a unix app called rdist. It was great. We used it to manage the different desktops, deploy applications, etc.
A reply to someones comment about work space. When you setup applications, just make sure their default save location is in such a directory (Also, use NTFS to enforce it). Now, you don't touch files from the directory unless files are XXX days or so.
The University of York used to do this idea. The computers would network boot to a small menu system (probably in DOS or something). You could either choose to Boot windows (whereby the Hard Disk was chainloaded) or Rebuild the PC.
Rebuilding the PC downloaded an image from a central server and re-imaged C:
If, however, the menu system noticed the time was after 1:00am and the PC hadn't been rebuilt for 24hours, it would force a rebuild, cleaning up any left over problems.
The system was enforced by removing the Logoff option from windows, requiring users to reboot after a session.
The only problem was, as mentioned above, that if you're working an all nighter on your project, forgetting to save then, when Windows crashes at 5am the rebuild will begin and wipe out your crucial temp files.
I suppose the solutions to this are A) put $TEMP on D:, a non-imaged partition for general junk or B) only re-image if the PC has been idle for a set amount of time (e.g. hold at the menu system for an hour then re-image)