<div dir="ltr">Hi, comments in line below...<br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 26, 2015 at 7:21 AM, Michael Paoli <span dir="ltr"><<a href="mailto:Michael.Paoli@cal.berkeley.edu" target="_blank">Michael.Paoli@cal.berkeley.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">So, ... my thoughts/comments ... </blockquote><div><br></div><div>Thanks for your thoughts and comments, Michael, really appreciate it! <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Documentation?  Google doc(ument), ... that could be helpful -<br>
especially for those that can't (re)read the list archive, and haven't<br>
seen the earlier emails (or no longer have them).  I might also suggest<br>
wiki.  </blockquote><div><br></div><div>We do have a wiki, but it does not have that much info on it.  It is mostly a high-level overview:<br><br><a href="http://partimus.org/wiki/Provisioning_Server">http://partimus.org/wiki/Provisioning_Server</a><br><br></div><div>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:<br><br><a href="https://docs.google.com/document/d/1UEgt_fkGUVdANcnZ1W2S5Rv15Hx3S92Ynn9Mui3xB_E/">https://docs.google.com/document/d/1UEgt_fkGUVdANcnZ1W2S5Rv15Hx3S92Ynn9Mui3xB_E/</a><br><br></div><div>We do also have a relatively high level summary of the server set up <br><br><a href="https://docs.google.com/document/d/1zs4_G-hvTDho1K9lP4Nrcz3BqPdw7gIczESu5f7V114/">https://docs.google.com/document/d/1zs4_G-hvTDho1K9lP4Nrcz3BqPdw7gIczESu5f7V114/</a><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
So, ... I guess one of my questions - why a custom ISO image, instead<br>
of, e.g. USB flash drive?  </blockquote><div><br></div><div>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. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Also ... much discussion/mention (I trimmed out a lot of it) regarding<br>
which distribution/flavor, which software packages, etc.  I'm curious<br>
too if anyone's taken a serious, and recent, look at DebianEDU<br>
(SkoleLinux)?  DebianEDU is also a Debian "pure blend" - which means it<br>
*is* Debian - just uses some specific Debian meta-packages to pull in<br>
certain collections of packages from Debian.<br></blockquote><div><br></div><div>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:<br><br><a href="https://docs.google.com/spreadsheets/d/1_s0E7w40zs80yZNrVRqupml6jqADKjD9XoJ3uFkhQMw/edit#gid=0">https://docs.google.com/spreadsheets/d/1_s0E7w40zs80yZNrVRqupml6jqADKjD9XoJ3uFkhQMw/edit#gid=0</a><br><br></div><div>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.<br></div><div><br></div><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
=== Software requirements<br>
</blockquote>
My concern with these other two distros is that they will come with a heavy<br>
desktop, such as Unity.  Until we get her better hardware, it seems to me<br>
that staying with Lubuntu is a good idea.<br></blockquote></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Following from my earlier notes, I would like to suggest attaining the<br>
goals outlined below, to wit:<br>
<br>
## Goal workflow for workstation install:<br>
<br>
        * teacher inserts CD into machine and reboots it from said CD<br>
        * teacher needs to only click a couple of times to launch the<br>
install process<br>
        ---- this may also involve choosing a network name for the PC<br>
        * teacher can remove the CD and walk away, whilst the PC does<br>
its thing on the network<br>
</blockquote></blockquote></blockquote></blockquote></blockquote></blockquote>
<br>
Not sure how current that description is regarding goals - sounds a bit<br>
different than as I heard (or interpreted?) it at my earlier hearing.<br>
Something that works like that though, where the CD can be removed that<br>
early, sounds rather like a glorified PXE boot - or approximation<br>
thereof.  But has those on (I presume) the school's network ... so that<br>
would have to go a quite different means of install, as it couldn't<br>
actually PXE boot, due to likely conflicts with school's network setup<br>
(e.g. we can't go mucking about changing school's DHCP server<br>
configuration in general).  Anyway, something along those line is<br>
*possible*, but it would be more like a Debian Fully Automated Install<br>
(FAI), or Red Hat KickStart - but started from CD rather than a PXE<br>
boot.  That does, however, have the advantage that the "target" host can<br>
be booted in place and installed there - no need to change network.  But<br>
it also has disadvantages - e.g. more challenging to do install direct<br>
on school's (untrusted) network, and to do so securely, more difficult<br>
to have that use some type of centralized boot/install - e.g. may<br>
somehow need to tell target systems the server that they proxy through<br>
for the build, etc., and may not be feasible to have that automatically<br>
detected (whereas PXE boot there should be no need to manually tell the<br>
clients that, as they'd pick it up from the PXE/TFTP server), or if<br>
doing that from CD without such a build server, would likely need to<br>
tell the target hosts more stuff manually, such as proxy settings, and<br>
would push more complexity to the CD (or DVD, etc.) ISO, rather than<br>
having it on build server.  Without a build server would also lose the<br>
efficiency and speed of using centralized build server to proxy and<br>
cache most of the relevant data needed for install - thus could be quite<br>
a lot slower on network as build targets wait to suck the data from The<br>
Internet, individually, each on the school's network.<br></blockquote><div><br></div><div>No, in the past, there was no data sucked down from the Internet.  It all came from the provisioning PXE boot server<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
System updates may or may not be installed by a remote technician, or<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
automatically. From a break-prevention point of view I prefer the former<br>
(or a technician at the school can be trained); for the school's<br>
independence, the latter may be more relevant.<br>
</blockquote></blockquote></blockquote></blockquote></blockquote></blockquote>
<br>
Various possibilities there.  There may also be regulatory/legal matters<br>
(e.g. school policy, privacy, etc. - e.g. exactly what can volunteers -<br>
even potentially - have access to, and requiring what<br>
authorization/permission/sign-<u></u>off for such - even if most or all of the<br>
data the school would generally have particular interest to protect<br>
would never be viewed/inspected etc. by such volunteers).<br></blockquote><div><br></div><div>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. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
At any rate, since the server is to host a master image, I'd like to<br>
insist that the machine /needs/ keeping up to date and secure from any<br>
non-authorized users in the school, or super-savvy/curious students :-)<br>
</blockquote></blockquote></blockquote></blockquote></blockquote></blockquote>
<br>
Students *will* be curious and, uh, "experiment", etc.  Things *will*<br>
happen.  So, ... should take into reasonable account things that may<br>
happen that aren't all that improbable (e.g. someone breaks into school<br>
over weekend and steals some hard drives from some of the computers ...<br>
or the whole computer; someone reboots host from a Knoppix DVD to see<br>
what they can do/change/inspect, etc.).<br></blockquote><div><br></div><div>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. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
May also be quite feasible to do a "build" server that could be<br>
multi-functional</blockquote><div><br></div><div>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. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br></blockquote></div>-- <br><div class="gmail_signature">Christian Einfeldt</div>
</div></div>