[Tech] Partimus (PXE?) (nearly?) unattended install solution(s?)
Michael Paoli
Michael.Paoli at cal.berkeley.edu
Thu Mar 26 07:21:18 PDT 2015
So, ... my thoughts/comments ... and pardons if I'm covering something
that was already covered, or going "wrong direction" (or potentially so)
from something that may have been decided earlier or "long ago" ...
anyway, kind'a jumpin' in here mid-stream ... and I may not have all the
attributions included on some of the (notably earlier) referenced
content/excerpts (sorry about that, but trying to keep it fairly
readable and not too horribly long).
Anyway, my thoughts/comments in-line below, among references/excerpts
(and sorry if I might drop out some relevant bits - trying to keep it
from being "too" long).
> Date: Mon, 23 Mar 2015 12:34:54 -0700
> Subject: Re: Partimus / PXE unattended install solution
> From: Christian Einfeldt <einfeldt at gmail.com>
> To: "dch.tai" <dch.tai at gmail.com>, Eric Burke <eburke1994 at gmail.com>,
> "Elizabeth K. Joseph" <lyz at princessleia.com>,
> Jim Stockford <jim at well.com>,
> Michael Rojas <ledworldwide.solutions at gmail.com>,
> Grant Bowman <grantbow at gmail.com>
> Cc: "tech at lists.partimus.org" <tech at lists.partimus.org>
>
> Hi Tai,
>
> thanks for your great work ! Also, I am cc'ing everyone, because I am not
Yeah, great, thanks!
I just joined the tech at lists.partimus.org, so that may make at least one
thing simpler. (We'll see if I can actually keep up on reading it.)
> sure who is on the tech list, and Lyz has sent in a trouble ticket to Dream
> Host, because it has not been archiving the tech list. I will send an
Ugh, Dream Host - I've been struggling with them with BALUG.org for
around 2 years now on trying to get them to have the BALUG.org list
archives working and for them to stop (re)breaking them ... good luck
on that - I've been through many trouble tickets with them on that, ...
and demoted Dream Host to "no confidence" / "would not recommend".
They'd been generally pretty solid earlier, but last about two years,
not so. Since Partimus is 501(c)3, there may also be a lot of free
(and/or deeply discounted) options available besides Dream Host one may
wish to consider. Just sayin'.
> email to the tech list asking everyone to put up their hands if they can
> see the emails coming through to that list. Thanks!
And if it's quite like most other busted Dream Host archiving, yes,
messages generally go through, but the archiving is generally quite
busted (to paraphrase from what they tell me, the data is there (so they
claim), but their present host(s) can't keep up with it, and thus fail
to make it available via web archive, and they're looking to / working
on upgrading to resolve the issue ... or so they've been telling me for
about 2 years now). I've sometimes seen them also break it so the list
traffic doesn't even go through, but that's been the more rare exception
- and is generally more obvious when it occurs.
Documentation? Google doc(ument), ... that could be helpful -
especially for those that can't (re)read the list archive, and haven't
seen the earlier emails (or no longer have them). I might also suggest
wiki. In any case, something like that could allow folks to relatively
easily see/edit more summary information of where
decisions/communications have gotten Partimus to, in terms of what's
been done, tried, is planned, being considered, etc. (and perhaps even
why) - and may be much easier for folks to get "up to speed" via
something like that, rather than trying to do, e.g., a chronological
reading of list archives (though too, quite nice to have such archives,
and with persistent web URLs, so they can be conveniently referenced -
including specific earlier list postings). (Alas, Internet Archive
didn't capture Partimus' tech list.)
> My comments are in line below.
>
> On Mon, Mar 23, 2015 at 10:38 AM, Tai Kedzierski <dch.tai at gmail.com> wrote:
>
>> Some notes of what I've done, and a request for advice, as well as
>> suggestions for Abigail. Please feel free to disagree and improve!
>>
>> === ISO Customization
So, I guess one of my first questions - what exactly are the objectives?
As I understand it (please correct me if I'm wrong), the general
objective(s):
o Build some custom ISO DVD image, that would:
o boot from that, host server then becomes a DHCP/PXE/TFTP
boot/install server, target hosts are then PXE booted from that
server, and automagically installed and configured with Ubuntu (or
Kubuntu, Xubuntu, Lubuntu, or some other Ubuntu flavor or
derivative) in a manner suitable for use as Partimus intends for
end-users (school environment).
So, ... I guess one of my questions - why a custom ISO image, instead
of, e.g. USB flash drive? I'd think in general somewhat easier to do to
bootable flash, having advantages:
o can be significantly larger capacity than DVD if/as needed
o more convenient size
o faster/easier to update/rewrite
o avoid the hassles/time of mastering ISO image
o avoid limitations of (mostly) read-only media
o avoid the waste of write-once (+-R) media
About the only disadvantages I can think of doing such on flash:
o moderately higher cost of boot media (e.g. $8.00 USD for 32G vs $0.20
USD for ~5G) - but unless quantities are to be large, and costs large
relative to other costs, I'd think this may not be much of a factor.
o not write-protected - someone can easily alter the contents of flash
media - that can also be a disadvantage, e.g. if one doesn't want it to
be changed (or easily changed) by those it's handed off to (or others
that may get their hands on it).
>> I had a go at the ISO customization task over the week-end. Unfortunately
>> the instructions are old, and oscillate between helpful and omissive... My
>> resulting ISO caused kernal panic before even loading boot, but I think I
>> know where to look to troubleshoot that...
Just speaking for myself, I've not (at least recently) looked over the
documentation for creating customized Ubuntu (& similarly based) ISOs.
>> I've started constructing a bash script to automate as much of it as I can
>> (it's also a good way to re-verify knowledge ;-) )
Good to have documented reproducible repeatable means. :-)
>> For the technically inclined, you can find that script here
>> https://github.com/taikedz/handy-scripts/blob/master/in-progress/customiso/autobuild.sh
--> https://github.com/taikedz/our-pxe
And better yet to have such under some kind of version control. :-)
>> === PXE Server / machine boot (help needed?)
>>
>> I also tried setting up a server to centrally serve ISO images over PXE
>> with a tftp server. Again, shaky tutorials abound, no end-to-end solution.
>> I had troubles with (I think) setting up an internal DNS and having my VMs
>> start there (VirtualBox does not have any "BIOS" settings as far as I've so
>> far seen)
I've done similar under Debian ... PXE boot server that actually allows
one to select among a few distributions/flavors/architectures (I think 2
Debian, and one or two Ubuntu). I tested it mostly using qemu-kvm,
rather than VirtualBox (actually that's just for typical test target
hosts - works on physical targets too) ... but overall ought be pretty
much the same (I actually have both qemu-kvm and VirtualBox on my
<cough, cough> server (it's a laptop, but to a relatively large extent I
treat and use it more like a "server" than a "laptop"). I do also have
VirtualBox on that same server, and do sometimes use it too ... maybe
I'll do a bit more testing with that, but last I tried it, I've got
stuff set up so I can PXE boot a guest VM just fine - and ought be able
to do it from VirtualBox too just fine - I'll have to give that a try.
Don't recall the details, but I believe they both have ways to either
access (virtual) BIOS/CMOS setup - or if not (quite) that, to at least
select boot device, etc.
Some semi-random but related points (and also touches bit upon stuff
further below). The Operating System of the PXE boot/install/etc.
server is *highly* independent of the target operating system(s) being
installed. However, that being said, it can be easier and more
efficient if they're *relatively* similar. Notably some reduction of or
limitation in variation there can ease the differences and range of
skill sets needed to support the installed targets, and the PXE boot
server used to install them - which can be fair to significant
advantage. Also, similar to same OS can ease updating of caches and
data used for installation, along with updating of the PXE boot server.
At least in theory, ideally, if they're same operating system, flavor,
and architecture, the installed targets can take advantage of the PXE
server downloading and using mostly the same software, thus overall
reducing upstream bandwidth requirements and complexity, and reducing
overall complexity of maintaining combined infrastructure of target and
PXE boot server. Nevertheless, not a huge deal if they're not precisely
matched on OS flavor - but closer is typically better. E.g. if target
is, say Kubuntu, if PXE server is Kubuntu and same architecture, that
would be a likely ideal match, but another flavor of Ubuntu and same
architecture, would be nearly as good. And close runner-up would be
Linux flavor in same general family, e.g. Debian and Debian derivatives
(of which Ubuntu is one). Things get more complex as one gets farther
from that (e.g. deb based vs. rpm based, some other package management
system, some other kernel or operating system type - e.g. BSD, etc.).
Also ... much discussion/mention (I trimmed out a lot of it) regarding
which distribution/flavor, which software packages, etc. I'm curious
too if anyone's taken a serious, and recent, look at DebianEDU
(SkoleLinux)? DebianEDU is also a Debian "pure blend" - which means it
*is* Debian - just uses some specific Debian meta-packages to pull in
certain collections of packages from Debian.
>> If I can get this much fixed, I can put together a comprehensive guide on
>> setting up the PXE component with better documentation and caveat
>> highlighting.
As I mentioned, did fair bit of PXE boot setup earlier ... I should
check its status ...
# diff TEMPLATE pxe
11c11
< PATHTOISO="${PATHTOISO:-$(awk '/^[ ]*#/
{next;};{if($2=="/media/cdrom9"){print $1;exit;};}' /etc/fstab)}"
---
> #PATHTOISO="${PATHTOISO:-$(awk '/^[ ]*#/
{next;};{if($2=="/media/cdrom9"){print $1;exit;};}' /etc/fstab)}"
14c14
< PXE=
---
> PXE=y
32c32
< #NETWORK=bridge=br0
---
> NETWORK=bridge=br0,mac=52:54:00:d8:2a:83
# >>/dev/null 2>&1 ./pxe &
[3] 12099
#
...
No bootable device.
... too many devices, too few IPs ... had to reconfigure my DHCP server
to enable PXE booting the target host ... reboot target host (VM) ...
... and it's PXE booted to slightly customized menu I set up, that
allows selections for debian-i386, debian-amd64, or ubuntu-server-amd64
(I'd earlier set up those 3, as I was most interested in the first 2,
and the 3rd was quite easy to add as an Ubuntu flavor with default PXE
config layout that almost entirely didn't conflict with the first two -
so easy drop-in addition). And to try one ... picking
ubuntu-server-amd64 ... picking rescue mode (since I didn't give this
virtual machine a drive to install onto) ... and it pulls everything it
needs from network, booted fine and fully into rescue mode (could just
have easily selected to do an install ... if I'd given that host a drive
to install onto). And now that I've still got the DHCP server suitably
configured, retrying with VirtualBox (more manual config bits, as I
don't have a template in place for that ...)
virtualbox ... New ... Next ... (Name) pxe OS Type Operating System ...
Linux ... Version ... Ubuntu ... Next ... Next ... (uncheck Start-up
Disk) ... Next ... Continue ... Create ... Settings ... Network ...
Attached to: Bridged Adapter Name: br0 Advanced Mac Address:
525400D82A83 (matched to that used for qemu-kvm PXE target host and in
DHCP configuration) ...
# vboxmanage modifyvm pxe --biosbootmenu messageandmenu
> --bioslogodisplaytime 10000
Start (... first Run Wizard ...) Next ... Next Start
F12 ...
l) LAN
FATAL: Count not read from the boot medium! System halted.
Well, whatever, I don't seem to be getting that to work with
virtualbox 4.1.18-dfsg-2+deb7u4 amd64
... even when I use tcpdump on the br0 interface, I see no traffic
to/from Ethernet MAC 525400D82A83, whereas if I do it with qemu-kvm pxe
guest host using that same Ethernet MAC, tcpdump clearly shows me that
traffic on br0. Anyway, works fine with qemu-kvm - not sure why the PXE
booting doesn't work for me with VirtualBox. Whatever.
... and DHCP server back as it was before, so I can continue with
"business as usual" (so the work laptop can also get an IP).
>> A lot of it requires manual work so cannot be so easily automated unless I
>> prepare a template, and even then may depend on the target network
>> infrastructure.
Very true - target network infrastructure may require fair amount of
flexibility on a PXE/boot/install server to be used in relatively
arbitrary (school) environments to do (re)builds/(re)installs on-site.
E.g. environment may have and use RFC-1918 Intranet IPs, and one would
want to use RFC-1918 Intranet IPs for build (sub-)net for PXE boot
target hosts, but to avoid potential conflict with (school) install
environment, that needs to be separate (sub-)net (school may have -
likely has, DHCP server, so can't generally do PXE boot of target hosts
direct on target school network), and any RFC-1918 Intranet IPs picked
for build (sub-)net may conflict with school network - at least without
suitably reconfiguring build (sub-)net first (and using Internet IPs for
build subnet may conflict with school network and/or other uses of those
Internet IPs). So, probably want something where one can relatively
easily select/specify the particular RFC-1918 Intranet subnet to be used
for build (sub-)net. Some semi-automagic assistance might also make
that easier (e.g. once connected to school network, some checks on the
connected (sub-)net, and perhaps routability/reachability of some
potential IPs, may help aid in automagically making/suggesting a
suitable build (sub-)net that is improbable to have any type of
conflict).
>> **Is there anyone who could offer guidance on setting up BIOS / etc so
>> that a machine can be specifically pointed in BIOS to the PXE server?
Not fully sure about VirtualBox - I'd think it should've worked as I
tried it (seems like it ought to) - but the requisite network traffic
seemed to not occur when I tried that. Does work fine for me with
qemu-kvm. I've also likewise used actual physical host(s) to test the
PXE boot with - that also worked fine (but don't presently have such a
convenient working spare available ... but that may change if I manage
to fix one bit of hardware that's also on my "todo" list anyway).
I also find virsh and friends to make the managing of qemu-kvm quite a
bit easier (so far I've had no need or reason to deal directly with
specific qemu-kvm commands at all).
> I am continuing to do outreach to try to build up a community of people who
> might be able to help you out, including Charlie Reisinger and others.
>> I am testing on VirtualBox, but I suspect many real machines also just
>> look for the network's default DNS server... over which I have little
>> control in fact, and the teachers may hit a similar problem...
"real machines" ... PXE booting, they use DHCP (and its extensions to
handle PXE boot), + TFTP ... so if there's DHCP server, they use what
they get from that - including (typically) DNS configuration. That's
also why I'm presuming we'd generally need to use separate (sub-)net for
the PXE host target build systems - as we generally couldn't go mucking
about with, e.g. school's DHCP server and tell 'em something like, "Oh,
for this list of Ethernet MAC addresses, can you specify their next/boot
server is this IP we're using, and this file to boot from?" ...
generally not gonna fly. Building on-site should be minimally invasive
to the school's network.
>> Alternatively, I might need to put together a PXE booting CD which has the
>> presets loaded into it (similar to what I saw at the Uni but not sure...)
>> which would be able to allow us to do away with having to even set up a
>> local DNS server
I'd think we'd do the build (sub-)net NATed behind the build server, so
the build server would consume all of one IP on the school's network
(likely picked up via DHCP from school DHCP server). *After* the target
hosts are built, *then* they could be moved to the school's network(s),
as at that point they'd generally (typical environments) use DHCP to get
their IP, DNS, etc. on school's network (and/or IPv6 autoconfiguration,
etc.) But PXE is IPv4, so needs be separate (sub-)net for the build, to
avoid conflict, for the various reasons already mentioned.
>> === Software requirements
> My concern with these other two distros is that they will come with a heavy
> desktop, such as Unity. Until we get her better hardware, it seems to me
> that staying with Lubuntu is a good idea.
>>>>>> Following from my earlier notes, I would like to suggest attaining the
>>>>>> goals outlined below, to wit:
>>>>>>
>>>>>> ## Goal workflow for workstation install:
>>>>>>
>>>>>> * teacher inserts CD into machine and reboots it from said CD
>>>>>> * teacher needs to only click a couple of times to launch the
>>>>>> install process
>>>>>> ---- this may also involve choosing a network name for the PC
>>>>>> * teacher can remove the CD and walk away, whilst the PC does
>>>>>> its thing on the network
Not sure how current that description is regarding goals - sounds a bit
different than as I heard (or interpreted?) it at my earlier hearing.
Something that works like that though, where the CD can be removed that
early, sounds rather like a glorified PXE boot - or approximation
thereof. But has those on (I presume) the school's network ... so that
would have to go a quite different means of install, as it couldn't
actually PXE boot, due to likely conflicts with school's network setup
(e.g. we can't go mucking about changing school's DHCP server
configuration in general). Anyway, something along those line is
*possible*, but it would be more like a Debian Fully Automated Install
(FAI), or Red Hat KickStart - but started from CD rather than a PXE
boot. That does, however, have the advantage that the "target" host can
be booted in place and installed there - no need to change network. But
it also has disadvantages - e.g. more challenging to do install direct
on school's (untrusted) network, and to do so securely, more difficult
to have that use some type of centralized boot/install - e.g. may
somehow need to tell target systems the server that they proxy through
for the build, etc., and may not be feasible to have that automatically
detected (whereas PXE boot there should be no need to manually tell the
clients that, as they'd pick it up from the PXE/TFTP server), or if
doing that from CD without such a build server, would likely need to
tell the target hosts more stuff manually, such as proxy settings, and
would push more complexity to the CD (or DVD, etc.) ISO, rather than
having it on build server. Without a build server would also lose the
efficiency and speed of using centralized build server to proxy and
cache most of the relevant data needed for install - thus could be quite
a lot slower on network as build targets wait to suck the data from The
Internet, individually, each on the school's network.
>>>>>> ## Server install/maintenance
>>>>>>
>>>>>> Installation of the server may need sending someone onsite, or we can
>>>>>> prepare an image that the teacher can install, with a
>>>>>> post-install script
>>>>>> to finish the job.
>>>>>>
>>>>>> The server should be able to just run headless and will probably be in
>>>>>> command line mode unless specified otherwise (who normally performs
>>>>>> maintenance?)
I'm presuming some proposition of a semi-permanent "build" server by
that? But targets booted from CD, not PXE boot? Build server also
potentially becomes a (relatively) critical point of failure in such
infrastructure.
>>>>>> System updates may or may not be installed by a remote technician, or
>>>>>> automatically. From a break-prevention point of view I prefer the former
>>>>>> (or a technician at the school can be trained); for the school's
>>>>>> independence, the latter may be more relevant.
Various possibilities there. There may also be regulatory/legal matters
(e.g. school policy, privacy, etc. - e.g. exactly what can volunteers -
even potentially - have access to, and requiring what
authorization/permission/sign-off for such - even if most or all of the
data the school would generally have particular interest to protect
would never be viewed/inspected etc. by such volunteers).
>>>>>> At any rate, since the server is to host a master image, I'd like to
>>>>>> insist that the machine /needs/ keeping up to date and secure from any
>>>>>> non-authorized users in the school, or super-savvy/curious students :-)
Students *will* be curious and, uh, "experiment", etc. Things *will*
happen. So, ... should take into reasonable account things that may
happen that aren't all that improbable (e.g. someone breaks into school
over weekend and steals some hard drives from some of the computers ...
or the whole computer; someone reboots host from a Knoppix DVD to see
what they can do/change/inspect, etc.).
Oh, another thought ... PXE & Wake-On-LAN. Could potentially be able to
nicely coordinate and use Wake-On-LAN with PXE, and, e.g., set PXE
server to automagically power-up (via Wake-On-LAN) the target build
hosts, and even, e.g. at a later time (like overnight), and even stagger
their starts (power-on), so that first would cause PXE build server to
cache all the relevant bits to be downloaded, and all the subsequent
build targets would have the speed advantage of pulling that from build
server's cache, rather than The Internet - and the staggering would also
help them not all pound upon PXE build server at same time (which would
be quite nice if one does hundreds or more targets at the same time ...
or build (sub-)net/LAN itself isn't all that speedy (which may be the
case with lower-end, older, donated or less expensive equipment).
... and some earlier background bits (end of my comments here).
May also be quite feasible to do a "build" server that could be
multi-functional - notably work as PXE build server (on dedicated build
(sub-)net), and also be able to function as a build server directly on
school's network (not using PXE on that, but targets booted from custom
ISO, which then leverages use of the local build server) ... the latter
would be more complex to implement, but would avoid needing to move
target hosts from build (sub-)net to school network after build ... but
no reason both setups couldn't be done on one server ... "just" more work
to implement and maintain would be all ... and could then potentially
use either method, depending upon the environment installed into (or try
both for a while, and later settle to just maintaining and setting up
for one method).
>>>>>> I propose the following deliverables:
>>>>>> * An install image with the required software and
>>>>>> very-few-questions-asked
>>>>>> * PXE server serving the image
>>>>>> * Pre-seed file served from PXE server
>>>>>> * PXE server install image itself (in case the server needs
>>>>>> resetting) and/or install procedure
>>>>>> * Delivery on DVDs for archival and off-Internet purposes
>>>>>> * Hopefully, a full build manual for future maintainers
>>>>>>
>>>>>> Tasks to attain this, as far as I can see, are:
>>>>>>
>>>>>> * Create custom "ISO" of target desktop setup (rather, dir structure
>>>>>> for serving over the web) from Ubuntu server
>>>>>> * Prepare the pre-seed file (which needs to include installation of
>>>>>> Lubuntu desktop) (this is the workaround I can imagine to get around
>>>>>> Lubuntu's lack of netboot)
>>>>>> * Prepare a PXE server setup
>>>>>> * Prepare an image of the PXE setup (which will include the contents
>>>>>> of the target ISO)
>>>>>>
>>>>>> ===
>>>>>>
>>>>>> Resources I've found most relevant so far:
>>>>>>
>>>>>> - UnattendedInstall CD :
>>>>>> https://help.ubuntu.com/community/Installation/UnattendedCD
>>>>>> - Custom CD incl pre-seed :
>>>>>> https://help.ubuntu.com/community/InstallCDCustomization
>>>>>> - PXE setup : https://help.ubuntu.com/community/PXEInstallServer
>>>>>>
>>>>>> For Lubuntu, this may require using tasksel to install Lubuntu on top
>>>>>> of a server base, as the std Lubuntu CD does not have the
>>>>>> requisite config
>>>>>> files ( /netboot )
>>>>>>
>>>>>>> Eric has found a documentation page that might be helpful for us in
>>>>>>> starting out the PXE boot project:
>>>>>>>
>>>>>>> https://help.ubuntu.com/community/PXEInstallMultiDistro
>>>>>>>
>>>>>>> Tai has sent me an email about the Google doc that I circulated.
>>>>>>> Elizabeth tells me that doc is actually for a specialized
>>>>>>> manual install
>>>>>>> .iso, not a PXE-boot .iso, so again my apologies if I have
>>>>>>> started us down
>>>>>>> the wrong road, and thanks for that correction, Elizabeth.
>>>>>>> Here is a link
>>>>>>> to that Google doc:
>>>>>>>
>>>>>>> https://docs.google.com/document/d/1UEgt_fkGUVdANcnZ1W2S5Rv15Hx3S92Ynn9Mui3xB_E/edit?usp=sharing
>>>>>>>
>>>>>>> Eric Burke's link above might be a better starting point, I'm not sure
>>>>>>>
>>>>>>> More comments below in response to a recent email from Tai:
>>>>>>>
>>>>>>> On Wed, Mar 18, 2015 at 4:21 AM, Tai Kedzierski <dch.tai at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi Christian
>>>>>>>>
>>>>>>>> Thanks - I wasn't expecting the "League of Extraordinary Sysadmins"
>>>>>>>> gathering!
>>>>>>>>
>>>>>>>> Good to know there are others who will be able to provide insight!
>>>>>>>>
>>>>>>>> Rather than muck around in the document you provided (which has the
>>>>>>>> initial vital info!) would it be possible you share a separate
>>>>>>>> empty Google
>>>>>>>> doc to serve as a collaboration/communication area? I'll dump
>>>>>>>> the following
>>>>>>>> in it afterwards
>>>>>>>>
>>>>>>> Thanks, Tai. As I said above, I think I might have started us off on
>>>>>>> the wrong document, and maybe Eric Burke's link would be
>>>>>>> better? I don't
>>>>>>> know.
>>>>>>>
>>>>>>> At any rate, the document that I circulated is a copy, it is not the
>>>>>>> original, so if you would like to add the text below to that
>>>>>>> document, it
>>>>>>> doesn't bother me. If you would like to start another google document,
>>>>>>> that would be fine as well.
>>>>>>>
>>>>>>>> I had a quick look at PXE setup yesterday [2015/03/17] and it seems
>>>>>>>> the straightforward setup simply serves the installation media
>>>>>>>> over the
>>>>>>>> network instead of reducing steps to install - James's notes
>>>>>>>> seem to align
>>>>>>>> with this, as in there is customization done but the teacher
>>>>>>>> still has to
>>>>>>>> manually sit through the initial install screens (select
>>>>>>>> languages, accept
>>>>>>>> partitions, choose various options etc)?
>>>>>>>>
>>>>>>>> Probably what we are looking for then is an "Unattended install"?
>>>>>>>>
>>>>>>>> To that end I wanted to ask what the intended/acceptable workflow
>>>>>>>> was - when I was at the University of Edinburgh IT desk, our
>>>>>>>> workflow for
>>>>>>>> installing was:
>>>>>>>>
>>>>>>>> * Go to physical machine
>>>>>>>> * Reboot to special CD
>>>>>>>> * hit enter
>>>>>>>> * walk away with CD whilst the PC automatically downloaded from the
>>>>>>>> network and installed everything
>>>>>>>>
>>>>>>>> ##
>>>>>>>> Another issue I encountered was a lack of netboot/pxeboot.cfg files
>>>>>>>> on the Lubuntu ISO which might need working around (though
>>>>>>>> have not yet had
>>>>>>>> time to check if there are alternative methods).
>>>>>>>>
>>>>>>>> I'm sure there's a straighforward solution however.
>>>>>>>>
>>>>>>>> ##
>>>>>>>> I think Machine #3 (P4 @ 1.8 GHz + 500MB RAM) will be the target
>>>>>>>> candidate for becoming the server.
>>>>>>>>
>>>>>>>>>> For proper PXE + Customized ISO it would require work to integrate
>>>>>>>>>> it all;
>>>>>>>>>>
>>>>>>>>>> However we can break it into PXE as first goal; and until ISO
>>>>>>>>>> customization os done, I can certainly envisage a fully
>>>>>>>>>> automating script
>>>>>>>>>> for the rest of the installation of custom s.w and settings.
>>>>>>>>>>
>>>>>>>>> Hi, thanks for that info. I have found some of the notes from one
>>>>>>>>> of our Linux gurus about what he did with regard to making a
>>>>>>>>> Lubuntu PXE
>>>>>>>>> boot disc for another teacher. I have invited you to the
>>>>>>>>> google doc so
>>>>>>>>> that you can see it and possibly get a little bit of a jump on the
>>>>>>>>> project. In the meantime, I am going to try to assemble our
>>>>>>>>> gurus for a
>>>>>>>>> chat about the document, either in IRC or elsewhere, perhaps
>>>>>>>>> even in a chat
>>>>>>>>> in the document itself. I have invited you to the document,
>>>>>>>>> but here is a
>>>>>>>>> link to it:
>>>>>>>>>
>>>>>>>>> https://docs.google.com/document/d/1UEgt_fkGUVdANcnZ1W2S5Rv15Hx3S92Ynn9Mui3xB_E/edit?usp=sharing
>>>>>>>>>
>>>>>>>>> Here is a link to the summary of the Ascend school's Linux lab:
>>>>>>>>>
>>>>>>>>> https://docs.google.com/spreadsheets/d/1_s0E7w40zs80yZNrVRqupml6jqADKjD9XoJ3uFkhQMw/edit?usp=sharing
>>>>>>>>>
>>>>>>>>>> Can you provide them a server to serve as core PXE master, or will
>>>>>>>>>> we repurpose a desktop PC to this end?
>>>>>>>>>
>>>>>>>>> We will be looking for a server, but for now, we will probably
>>>>>>>>> repurpose a desktop machine.
>>>>>>>>>
>>>>>>>>>> How frequently do they need to do installs?
>>>>>>>>>>
>>>>>>>>> Initially, they will want to flash all 25 machines. Then it will
>>>>>>>>> be a couple times a month as the older machines fail.
>>>>>>>>>
>>>>>>>>>> Are you mostly installing Ubuntu derivatives?
>>>>>>>>>
>>>>>>>>> Yes, that is all that we are doing. We try to use as few distros
>>>>>>>>> as possible, and one of our board members, Elizabeth Krumbach
>>>>>>>>> Joseph, is a
>>>>>>>>> Ubuntu Community Council member. Plus Ubuntu has good
>>>>>>>>> documentation, which
>>>>>>>>> is good for a simple end user like me.
More information about the Tech
mailing list