[sf-lug] Fw: Another volunteer & next steps

[jim stockford]

there may be reasons to build some machines
uniquely (resource differences, user needs...),
just a tho't.

On Jun 19, 2007, at 2:29 PM, Jeff Bragg wrote:

> 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).
>
> On 6/19/07, Romel Jacinto <penguin at techbandit.com> wrote:
>>
>> >> 1. Evaluation with housing project about what their specific 
>> application
>> >> needs are.
>> >
>> > This one's kind of key, and will really determine if the project's a
>> > success or failure. For instance, if they __need__ Quickbooks then 
>> we're
>> > out of luck. Michael, are you planning to do this with Kami, or has 
>> it
>> > been determined already?
>>
>> I wasn't thinking of such a specialized application like Quickbooks, 
>> but
>> had more in mind more general user applications that may be wanted, 
>> i.e.
>> listening/watching multimedia or DVD's (may need to install codecs 
>> and add
>> relevant repositories).
>>
>>
>> >> 2. Training for computer lab managers.
>> >
>> > Wasn't aware there were computer lab managers. Maybe they could be
>> > trained (if necessary) to train the end users so that we aren't
>> > duplicating effort. Are they going to be responsible for ongoing
>> > maintenance of the machines/applying security updates, backups, 
>> etc.?
>>
>> I don't know for a fact that there is a lab manager, it was an
>> assumption.
>>
>> Personally I think there has to be a someone in that community
>> who can take a leadership role in maintaining the computers.
>> I think of it as sustainable computing: we teach someone who can teach
>> others.
>>
>> Setting up computers without a long-term support plan is a recipe that
>> doesn't have a high probability of succeeding.
>>
>>
>> > I'm not familiar with imaging technologies myself, but think if 
>> there
>> > are folks with the knowledge to do that, it'd be a great approach.
>>
>> I only brought imaging up because of the number of computers to be 
>> setup.
>>
>> In my mind once the base set of applications and other user-specified
>> configurations are set, that image can be deployed onto the other
>> computers since the hardware is essentially identical.
>> Might save time, but more importantly there is a known standard
>> configuration; this can save time and effort when performing
>> maintenance down the road.
>>
>> I'm most familiar with imaging technologies used on proprietary 
>> operating
>> systems, but I'd like to learn about implementing imaging in the
>> open-source world.
>> I've used G4U on occasion as a quick and dirty backup,
>> but have not used it in a mass deployment situation.
>>
>> --
>> Romel
>>
>> _______________________________________________
>> sf-lug mailing list
>> sf-lug at linuxmafia.com
>> http://linuxmafia.com/mailman/listinfo/sf-lug
> _______________________________________________
> sf-lug mailing list
> sf-lug at linuxmafia.com
> http://linuxmafia.com/mailman/listinfo/sf-lug