[Tech] Partimus (PXE?) (nearly?) unattended install solution(s?)

Christian Einfeldt einfeldt at gmail.com
Thu Mar 26 12:43:55 PDT 2015


Hi, comments in line below...

On Thu, Mar 26, 2015 at 7:21 AM, Michael Paoli <
Michael.Paoli at cal.berkeley.edu> wrote:

> So, ... my thoughts/comments ...


Thanks for your thoughts and comments, Michael, really appreciate it!


> 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.


We do have a wiki, but it does not have that much info on it.  It is mostly
a high-level overview:

http://partimus.org/wiki/Provisioning_Server

I would like to keep that wiki low-traffic, because I have found that as
wikis gain public attention, they attract trolls who like to deface and
damage it.  Just my two cents.  A google doc like our sandbox page is nice,
because AFAIK only people invited can edit it:

https://docs.google.com/document/d/1UEgt_fkGUVdANcnZ1W2S5Rv15Hx3S92Ynn9Mui3xB_E/

We do also have a relatively high level summary of the server set up

https://docs.google.com/document/d/1zs4_G-hvTDho1K9lP4Nrcz3BqPdw7gIczESu5f7V114/


>
> So, ... I guess one of my questions - why a custom ISO image, instead
> of, e.g. USB flash drive?


The cost of the flash drive is problematic, and we need to be able to
easily create lots of copies of the boot disc.  From the perspective of a
simple end user, here is how it worked well in the past.  James Howard
would prepare the boot disc.  We would make about 5 or six copies.  We
would start installing at client machine 1, put the disk in the machine,
and then hit enter a couple of times, and the client machine would start
grabbing all of the stuff off of the PXE boot server.  We could usually
image an entire lab of 15 to 20 machines this way in about an hour or 90
minutes or so.  It was super simple.  Please remember that a teacher with
even fewer skills than me will be creating clients on the network if one of
her client machines goes down.  We really want to make this install process
super simple, so at to empower the newbies to create a client machine
themselves.


>
> 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.
>

Every day, Ascend elementary school teacher Abigail Rudner has 100 kids
come through her Linux lab.  Some of the machines are older and slower than
others.  Some of the machines have as little as 500 MB of Ram.  Thanks to
the donation of David Eisenberg, some of that is going to change, as all of
the 15  machines he gave us have 1 GB or RAM at least.  But until we can
assure that we have machines with at least 4 GB of RAM, it is probably a
better idea to keep the desktop lightweight.  The kids that Abigail have
been teaching are familiar with the Lubuntu desktop.  We could experiment
with a new distro for the end of the school year that ends in June of 2016,
but for the rest of this year and the next year, let's make Abigail's life
easier by not throwing a new desktop environment at her.  That is my two
cents.  I am open to hearing other discussions.  But let's please bear in
mind that change is difficult for simple end users.  Please also bear in
mind that Abigail's classroom hour is only about 40 minutes long, when you
consider that getting children to transition and but away their books, get
in a line, and then for the next class to come in, is by no means a trivial
feat. Here is a summary of Abigail's lab at Ascend:

https://docs.google.com/spreadsheets/d/1_s0E7w40zs80yZNrVRqupml6jqADKjD9XoJ3uFkhQMw/edit#gid=0

The other thing is that Ubuntu has a big community, which allows simple end
users like Abigail and I to help ourselves a little bit more and be a
little bit more independent.  Having a huge user base is a great comfort,
because you are likely to see an answer for your question on-line.



> === 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.
>>
>
Yes, as you will see from the summary of Abigail's Linux lab linked above,
some of her machines are primitive, at least for the short term.


>
>  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.
>

No, in the past, there was no data sucked down from the Internet.  It all
came from the provisioning PXE boot server


> 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).
>

As long as Abigail Rudner is aware that an ssh tunnel exists, no one will
complain.  The high school principal and the vice principal know what we
are doing.


>
>  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.).
>

In that past, it was sufficient to have a login required, and the server
typically ran only in terminal mode.  There was no GUI to give an simple
intruder the option of mucking around.  That has always been sufficient
security in the past.


>
>
> May also be quite feasible to do a "build" server that could be
> multi-functional


Yes, the server is also a proxy server, which I understand to mean that if
you have 20 kids all watching a 15 minute video of the Sound of Music, then
after the first kid clicks on the video, the data will be cached on the
server and served up from the server, not over the network.


>
> --
Christian Einfeldt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.partimus.org/pipermail/tech-partimus.org/attachments/20150326/3291a2b3/attachment-0002.htm>


More information about the Tech mailing list