[Tech] Partimus (PXE?) (nearly?) unattended install solution(s?)
Alexandro Colorado
jza at oooes.org
Thu Mar 26 14:04:23 PDT 2015
Some comments inline
On Thu, Mar 26, 2015 at 2:32 PM, Tai Kedzierski <dch.tai at gmail.com> wrote:
> Hi all,
>
> Michael thanks very much for all those notes !
>
> Regarding the description of the goal workflow, it is "current" as in,
> it's the last that I suggested and none has yet overridden it. I feel I am
> about to though. But /after/ testing some more with alternatives.
>
>
>
> I am also adding Alexandro Colorado to this list, with the belowposted
> from a convo we started aside
>
> There have been quite a few suggestions of alternatievs now, so I will be
> wanting to gather all the info, sort and re-evaluate the goal workflow
> etc... if anybody has already been doing so, please send in!
>
> +++
> Clonezilla has been mentioned by a few - my concern with that solution is
> that, AFAIK, it requires the target disk to be the exact same size as the
> image. Since Partimus is sourcing disparate computers of varying specs,
> this might not be viable for us - unless someone knows otherwise?
>
Because is Linux, and is Lubuntu, I think is lightweight enough to
install on most HDD. Even if the HDD is larger than the image, is targeted
towards a classroom environment where the storage would probably not be
used or even locked down (using unionfs or something similar).
>
> +++
> PXE booting might require isolating a subnetwork during install, which may
> not be fully suitable once the school hits 20+ machines and needs to
> refresh all of them...
>
> Unless they're all fitted with wireless. Has anyone got a way of isolating
> from the main network without requiring a mass deployment of cables? (my
> site networking skills are fairly basic, maybe I'm missing a trick here)
>
> +++
> Customization from basic is pretty hairy.
>
> For those who've asked, the reason we are doing pre-customization is to
> have an image that has everything already on it. We're not burning the ISO
> to discs, but prepping it for serving as an online image over the local
> network.
>
Probably this is out of the scope but SuSE Studio is a great way to play
around with images and virtualization of the software that we want. It
allows you to custom setup whichever desktop, WM, special software, etc.
This would be a good sandbox to play with the costumization image. Also you
can test it from your browser, so even we dont end up using open suse, we
can put XFCE4, abiword, etc. and even test it fully on our own machines
using Virtualbox.
>
> +++
> remastersys is no longer maintained since.... many years. I don't want to
> download a binary off some any-site, so we'll have to see what options are
> available to us... remastersys is not in /main
>
> I've cloned a github repo but it'll take me some time to step through the
> code (if I am capable of that at all... I'm not used to doing code
> reviewing in the slightest....)
>
>
> +++
> Michael's alt dists
>
> @Christian we will have to ask you to look into those and decide. I'm
> continuing so far on the assumption of Lubuntu for now, though if you're
> getting more powerful machines in, can I suggest something with a MATE
> desktop or Xfce?
>
>
> +++
> Abiword - @Christian mentioned this previously, I've found the ODT (text
> processing) engine to be rather non-compliant with standards, specifically
> on document styling structure which is key not only for formatting but also
> automatic chaptering and sectioning. Alas, Abiword is a poor reflection of
> what FOSS can do in a properly deployed environment.
>
> Then, that's just me. I prefer LibreOffice as it's as standards compliant
> as it gets - it's the reference implementation from the Document
> Foundation, and handles "the other standards" well too so interoperability
> can happen smoothly.
>
I would recommend to stick with the needs of the client. Chances are
depending of the age-range that productivity suite won't be something big
in the curriculum (I might be wrong). Exchanging files and information
might happen more over HTML than on self contained documents. I would
recommend using Apache OpenOffice only if the hardware can handle it,
otherwise I would +1 Abiword or other lightweight editor like. If the kids
are too young a preffered option is Gcompris, which has it's own
wordprocessor.
http://gcompris.net/screenshots-en.html#wordprocessor
>
> Otherwise, you may want to look into OOo4kids:
> http://translate.google.com/translate?hl=en&sl=fr&u=http://educoo.org/OOo4Kids.php&prev=search
> Original site is in French but runs fully in English too.
>
I worked with Eric many years with OOo4Kids, however I can tell you that
development hasnt move since OpenOffice.org 3.4 unfortunately.
>
> +++
> I'm going to have a go at the option of using the OEM install mode of
> (L/X)Ubuntu with an rsync server...
>
> +++
> Michael's suggestion of an information repository that reflects the
> "current state" (as a wiki methinks) is a good one. Just in trying to
> reconcile the threads just now was not the most fun I've ever had...
>
> I can set up a digitalOcean droplet as a temporary shim, but that'll
> disappear once the project is complete. If Partimus use digitalOcean, I
> believe I'll be able to pass stewardship of it over instead...
>
There might be some commercial wiki service that can be used while the
project is on going, I mentioned this because of Christian fear of getting
it bandalized. I found out that wikis like Google Sites or Wikispaces hold
pretty well against these issues.
Of course there is another option of just using wiki's that are not as
popular but more secure like MoinMoin or MonkeyWiki
http://www.waywood.co.uk/MonkeyWiki/
They are very basic but gets the job done, and the Python architecture
makes it more resistant to bandalism.
>
> +++
> I've got all week next week to work on this. You'll hear from me :-)
>
> Oh, and let's have that multi-way chat/call. I can set up a Mumble server
> for this if everyone is comfortable with that.
>
+1
>
>
>
>
> Ciao tutti!
>
>
> ========
>
> On 25 March 2015 at 16:26, Alexandro Colorado <jza at oooes.org> wrote:
>
> On Wednesday, March 25, 2015 12:42:54 PM you wrote:
> > Hi Alexandro,
>
> > I had not considered remastersys thanks for reminding me; It does
> look like
> > it should help with the customization aspect very well. Perhaps a
> GUI may
> > be useful to any non-techs who need to do customization, and
> certainly
> > it'll speed up the initial version of the custom ISO; that being
> said, I'll
> > still be trying to get the command line procedure down...
>
> > All that's needed then is to make an Unattended install of the
> resulting
> > ISO... unless remastersys can do that too...
>
> > Will give it a try. Thanks!
>
> I didn't follow on the issue of unatended installation, this is a
> different
> issue.
>
> I am thinking if maybe CloneZilla could be a better way to act.
> http://clonezilla.org/
>
> Clonezilla will just clone your installation across multiple PC.
> Clonezilla
> has a server edition which will allow you to image 40+ desktops at
> once.
>
> http://clonezilla.org/clonezilla-SE/
>
>
> > On 24 March 2015 at 23:36, Christian Einfeldt <einfeldt at gmail.com>
> wrote:
> > > Hi,
> > >
> > > Thanks for your reply, Alexandro.
> > >
> > > Tai, here is the video to which Alexandro is referring. Thanks
> for this
> > > video link, Alexandro:
> > >
> > > https://www.youtube.com/watch?v=9K-iUJgFhWA
> > >
> > > On Tue, Mar 24, 2015 at 3:21 PM, Alexandro Colorado <jza at oooes.org>
> wrote:
> > >> Hello Tai,
> > >>
> > >> As I was telling Christian, I have been looking into the email he
> shared
> > >> with me, and I have investigated alternatives to your issue.
> > >>
> > >> I do see a bottleneck in the fact nobody has foot on the ground
> and
> > >> hardware issues might need some troubleshooting in the end.
> However I am
> > >> confident that if Partimus have access to previous
> implementations, this
> > >> can be done with less overhead.
> > >>
> > >> One of my recomendations is to view a youtube video of a guy
> spinning an
> > >> ubuntu OS. He uses something different from what you are using
> and might
> > >> be
> > >> a more straight forward solution (at least it has a GUI).
> > >>
> > >> I read your script but like you mention on the email is a bit old
> and not
> > >> that useful at the beginning and I think you might find this
> alternative
> > >> more pleasant on your OS costumization.
>
>
>
> ===
> Tai Kedzierski
>
> IT Services Specialist
> http://helpuse.com
> +44 (0) 7526 963 612 (portable GB)
>
> I use www.libreoffice.org
>
> *"Open Source Free Software is a matter of liberty, not price."*
> https://bitly.com/1gXkUcc
>
>
> On 26 March 2015 at 14:21, Michael Paoli <Michael.Paoli at cal.berkeley.edu>
> wrote:
>
>> 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.
>>>>>>>>>>>
>>>>>>>>>>
>>
>
--
Alexandro Colorado
Apache OpenOffice Contributor
882C 4389 3C27 E8DF 41B9 5C4C 1DB7 9D1C 7F4C 2614
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.partimus.org/pipermail/tech-partimus.org/attachments/20150326/f98d5c36/attachment-0002.htm>
More information about the Tech
mailing list