[H-GEN] Dealing with BYOD (Bring Your Own Device)

[David Seikel]

On Mon, 10 Sep 2012 18:02:04 +1000 Rick Phillips <rick at greyheads.net>
wrote:

> I work for a very large organisation which has a huge expenditure in
> laptops and PCs.  Due to looming money restraints, we are faced (as
> techs) with dealing with large numbers of various BYOD units of the PC
> (not Mac) type which we are told will start to appear.

BYOD will also include smart phones in the near future, or even now.  A
top end smart phone, with a $6 USB OTG adaptor, a small USB hub,
keyboard, and mouse, is more powerful than the desktop work station I
used to lug to HUMBUG meetings a few years ago.  Some of them you can
even plug into normal computer monitors.  They work just fine as an
ordinary computer.  Multi CPU cores running at a GHz or more, and a GB
of RAM makes for a decent work station for a lot of common tasks.

The hub, keyboard, mouse (and possible monitor) could be supplied by the
company and left on the office desk.  The USB OTG adaptors tend to be
generic, but some phones require their own adaptors.  Smart phone as
desktop replacement is not ready yet, but it's coming.

I have such a smart phone and I'm experimenting and writing software
for just such a future of BYOD smart phones.  Again, these are not Apple
devices, those tend to be locked down too much.

Though Android phones use Linux as it's kernel, they wont work so well
for your use case.  At least not yet, mostly due to lack of X11 in any
sort of decent setup.  You can VNC to a locally running X server, but
it's kinda clunky.  Still, it's something to keep an eye on for the
future.

> Our initial thoughts are to provide employees with a very limited list
> of supported laptops (say 3 models) which we could load our corporate
> Windows system onto without destroying their recovery partition.  This
> might work as we could use (say) Ghost to place any one of the three
> tailor made images on their machine.  Windows as we know rarely has
> the correct chipset drivers included in the OS and these would be
> manually pre-installed in each of the 3 images.  This plan is flawed
> too because models and chipset combinations change very quickly -
> even in the same model.
> 
> Another thought is that we could install a very tiny Linux OS (maybe
> DSL) which could include (say) VirtualBox with our corporate image
> already rolled up inside.  The idea is that the machine would then
> boot Linux and roll straight into VBox and then Windows without
> intervention from the user.  I favour this idea as we would not have
> to be so worried about what employees buy.  Deletion of the corporate
> install would be much easier too when or if an employee moved on.
> 
> I have once in the past set up a server which ran CentOS which
> contained VBox which started a Windows server instance in the
> background.  This worked very well.  This time I want the smallest
> instance of Linux to boot to a visible instance of the corporate
> Windows 7.
> 
> Has anyone been down this track?  I would welcome any thoughts.
> 
> Licensing is not an issue as we are diligent about purchasing licences
> for each machine and let's forget about any other privacy issues that
> people might believe we will run into.  I am looking for a purely
> technical solution to our coming problem.

If you want the smallest Linux, then starting from something like DSL
and cutting out what you don't need wont get you there.  I took over a
project that was using DSL, and it needed to cut the host OS down to
the bare minimum.  Slashing where I could, I got the DSL image, the
actual application, and enough data space for the application, down to
about 50MB.  DSL also took ages to start up (five minutes on his
hardware), mostly coz it is probing for every bit of hardware under the
sun.  The client was not happy with the boot speed or the footprint.

The main problem is that it's a generic system, designed to be a useful
generic desktop.  Lots of cruft you don't need, and lots of
dependencies between the cruft that's tricky to untangle.  So you
basically end up leaving a lot of the cruft on.

The client was happy to try it the other way, build from the ground up
the bare minimum of Linux OS needed to support his application.  This
resulted in a 13MB total footprint, that took 20 seconds to boot.  Over
half of that 20 seconds is the BIOS and boot loader getting to the
point where they load the Linux kernel.

Since he has a random assortment of PCs that this has to run on, the
kernel had a bunch of common drivers included, though not as modules.
This helped to keep the boot time and footprint lower.  Lots of
repeated over head when your drivers are modules that can be left out.
Not using modules means that lots of common hardware just works, no
probing needed.  I did both modules versions and built into the kernel
versions, to test that out.  Definitely saved space and time with the
built in drivers version.

We use http://www.landley.net/code/aboriginal/ as the basis for this.
Aboriginal Linux is designed to be the bare minimum you need to build a
self hosting Linux OS from scratch.  By "self hosting" it means that it
can build itself when running under itself, it has suitable compiling
tools.  This is then used to build whatever else you want on top of
the minimal self hosting OS running in QEMU.  It can also build things
like Linux From Scratch, and they are working on Funtoo (with the
Funtoo developers), plus bootstrapping other common distros.

I use Aboriginal Linux to create it's minimal image, automatically boot
itself in QEMU, and run build scripts that compile the rest of the
dependencies for my clients application, then the application itself.
The build scripts then put it all together into a disk image (minus the
build tools) suitable for dd'ing onto a USB drive that plugs into the
target hardware that it can boot from.

Building a similar system that includes QEMU in the resulting OS, and a
suitably prepared corporate Windows 7 disk image for your purposes
should not be too hard.

For an open source project that needs to build for a variety of OS's, I
have been using my experience on this Aboriginal Linux project to write
a script that boots up a succession of QEMU instances running that
variety of OS's, and doing scripted builds on each of them.  This
includes Windows XP and Windows 7.

Feel free to pick my brains.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.humbug.org.au/pipermail/general/attachments/20120910/0ab34cd8/attachment.sig>