[K12OSN] Responses to the central office

[Todd O'Bryan]

Hey all,

My department and the school are now on board with doing thin clients,
but now our purchase has to be approved by the Telecomm department at
the central office. When I called to talk to the director of networking,
he said we could do whatever we wanted, as long as we didn't connect to
the district network. Obviously, that makes the whole enterprise much
less attractive.

Below is a copy of an email I sent him outlining what I think are his
concerns with the plan. If people who don't mind being quoted (and
preferably have titles that central office folks would be impressed by)
wouldn't mind taking a look and responding, I'd really appreciate it. If
he responds with other issues, I'll let you know.

Thanks,
Todd

------------------------------------------------------------------------
Mr. Thompson,

As I'm asking for advice from other people who use thin client labs in
school districts around the country, I just want to make sure that I'm
having them address the concerns that you have.

Please take a look at the issues below and let me know if I've
mischaracterized them or have forgotten any particular concerns.

To be clear, we would be interested in creating a local network within
the classroom which would connect to a single Linux server. The server
would run all applications for the client machines. The clients would
not be directly visible to or from the network as all network traffic
would be handled by the server.

As I understand it, your concerns are:

1. The server would not have been configured by Telecomm and you can not
be sure that settings would not be changed in such a way that they would
interfere with normal operation of the network. Problems could include
address collisions with other machines on the network or the server
attempting to usurp roles which other machines fill (attempting to serve
DHCP to the network, trying to act as the school's Master Browser or
something similar), both of which would cause havoc.

2. Because the server would not be Windows-based and is not part of the
domain, you couldn't directly manage it and could not insure that it was
properly configured.

3. The server would be routing traffic from the clients to the network
and from the network back to the clients. Attaching a router to the
network can always cause problems.

4. Troubleshooting network problems caused by non-managed computers on
the network can be incredibly difficult. It is always time-consuming and
often tricky because non-standard software can interact with your
software in ways that make problems difficult to identify and resolve.

If I've missed anything or haven't sufficiently identified the issues,
please correct me. I'm hoping the people on the list I subscribe to can
figure out ways to sufficiently address the issues so that you'd feel
comfortable with a solution.

To give you an idea of the economies we're talking about here, here's a
breakdown of the cost to completely replace my lab:

~$3900  30 PXE-boot thin clients @ $129 each
~$2000  server built from parts, optimized as an app server:
        4 GB ECC registered RAM, 2 dual-core Opteron processors,
        2 SATA hard drives in a RAID array
        (assuming you eventually approve, we'd buy a second server to
        mirror the first as a backup in case of hardware failure)

Because we'd be using Linux (all the software I use to teach programming
is free and available in Linux versions), we wouldn't have to pay any
licensing fees.

In addition, because the thin clients do not run any of the
applications, they don't become obsolete nearly as quickly as desktop
machines. Buying a new server upgrades the entire lab and the thin
clients can be used for 7 or 8 years instead of the 5 or 6 year lifetime
we get with desktop machines.

Compare this with the $15,000 price tag you mentioned for lowest-level
desktops available with licenses and you can see why we're really
hopeful that we can make this work.

Thanks for your attention,
Todd O'Bryan