DD could simplify the repetitive aspects of imaging the machines, but it's ugly, and not particularly fast; it also requires that the destination drive be at least as big as the source drive, and any extra space on the destination drive will be rendered unusable (outside parameters of partition table). Using PXE it would be possible to largely automate this, but it would require a dedicated machine running TFTP and housing a copy of the desired image. I've never set one up to do this, but it doesn't appear to be terribly difficult; for only 15 machines, the process of setting up a build automation system would need to be pretty trivial to be worthwhile (except as a learning exercise).
<br><br><div><span class="gmail_quote">On 6/19/07, <b class="gmail_sendername">Romel Jacinto</b> <<a href="mailto:email@example.com">firstname.lastname@example.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Tue, 19 Jun 2007, Tom Haddon wrote:<br><br>>> 1. Evaluation with housing project about what their specific application<br>>> needs are.<br>><br>> This one's kind of key, and will really determine if the project's a
<br>> success or failure. For instance, if they __need__ Quickbooks then we're<br>> out of luck. Michael, are you planning to do this with Kami, or has it<br>> been determined already?<br><br>I wasn't thinking of such a specialized application like Quickbooks, but
<br>had more in mind more general user applications that may be wanted, i.e.<br>listening/watching multimedia or DVD's (may need to install codecs and add<br>relevant repositories).<br><br><br>>> 2. Training for computer lab managers.
<br>><br>> Wasn't aware there were computer lab managers. Maybe they could be<br>> trained (if necessary) to train the end users so that we aren't<br>> duplicating effort. Are they going to be responsible for ongoing
<br>> maintenance of the machines/applying security updates, backups, etc.?<br><br>I don't know for a fact that there is a lab manager, it was an<br>assumption.<br><br>Personally I think there has to be a someone in that community
<br>who can take a leadership role in maintaining the computers.<br>I think of it as sustainable computing: we teach someone who can teach<br>others.<br><br>Setting up computers without a long-term support plan is a recipe that
<br>doesn't have a high probability of succeeding.<br><br><br>> I'm not familiar with imaging technologies myself, but think if there<br>> are folks with the knowledge to do that, it'd be a great approach.
<br><br>I only brought imaging up because of the number of computers to be setup.<br><br>In my mind once the base set of applications and other user-specified<br>configurations are set, that image can be deployed onto the other
<br>computers since the hardware is essentially identical.<br>Might save time, but more importantly there is a known standard<br>configuration; this can save time and effort when performing<br>maintenance down the road.<br>
<br>I'm most familiar with imaging technologies used on proprietary operating<br>systems, but I'd like to learn about implementing imaging in the<br>open-source world.<br>I've used G4U on occasion as a quick and dirty backup,
<br>but have not used it in a mass deployment situation.<br><br>--<br>Romel<br><br>_______________________________________________<br>sf-lug mailing list<br><a href="mailto:email@example.com">firstname.lastname@example.org</a>