The Salopian Summer 2023

SCHOOL NEWS 21
The first e-prospectus. Around 2000
how to terminate the copper cables we
used for miles of indoor wiring.
The VPN solution turned out to be to
make our own switches. Linux – our
chosen flavour was Ubuntu - shipped
with some nifty code called ebtables
which allowed us to configure routing
in a computer full of network cards
by mac address - a sort of unique
telephone number for the PC. We could
say that this PC was permitted to use this
route through our box to communicate
with this server on this port. Thus, we
generated several rules for each PC
on the network. If the system didn’t
recognise the network card in the PC,
the network led nowhere. But where to
get the MAC addresses 6 - the network
card’s phone number - from? The
solution involved a big database, and
more utilities such as arp. Running arp
against a known machine gave us its
MAC address which was then stored
in a SQL table. Another routine then
pulled the MAC addresses out and ran
ebtables with them to let them through
to appropriate servers. The effect was to
stop House-to-House gaming, and even
to stop iTunes sharing in Houses.
It made us very unpopular, but it kept
the network working.
This design went through several
iterations. An early one had the pupil
file storage in the box itself, with each
box handling three Houses. This was
fast (a direct route on both sides) but
unwieldy, and one pupil once changed
Houses. Later ones had a single
pupil file server for each House to
which the PC was routed.
But things were getting complicated.
As well as the two SMB 7 Servers – a
main and backup – we had three House
firewalls, and separate pupil and staff
file servers, then backup systems. Each
client had to run a login script which
set up the required drive mappings
at login. This script got increasingly
complicated as services were added
and expectations grew.
We had, however, missed a trick. WiFi.
WiFi started slowly, but eventually
broke our model. We had designed
everything – in particular the SQL 8
tables for the switch firewalls – on the
back of one pupil, one IP address. WiFi,
after a few years of settling in, gave
pupils the option of connecting phones,
laptops, tablets and desktop PCs all
to our network. Our original notional
limit of around 1000 PCs began to look
woefully inadequate and we began to
run short of IP addresses as well. In
addition to all this, we discovered that
some foreign students had discovered
how to run virtual network cards
configured with a MAC address of their
choosing. A bit of judicious listening
gave them two or three staff MACs to
play with, and away they went with full
staff privileges.
We realised that changing systems was
a lot more difficult than building them
in the first place. Our setup with one IP
address per pupil wasn’t going to work
long term, so we began to fragment our
network and provide WiFi on a House
by House basis, connecting to the
central ‘DMZ’ for internet/email access.
IT became a provider of bought-in
services, and the Site slowly became
fibre-optically enabled.
In 1993, The School timetable was
held in the head of its creator, Mark
Mortimer (MM). A paper copy, with
the timetable in pencil, was kept in the
Common Room. If you wanted a copy,
you had to get it yourself with paper
and pen. Set lists were managed by the
head of department. It looked like time
for a change, though there were no
commercial packages to do the job in a
very niche market. We wrote our own,
over a few months. A web-based front
end managed modules to handle the
various lists we wanted, exam results,
registration and everything except
examination entries. The prospect of
Bob Kendall retiring (Examinations
Officer) a few years into the project
eventually forced a move to a much
more standard package, iSAMS, which
the School runs to this day.
iSAMS gave us all a clue about direction.
We were moving from a strange and
non-standard system, built as innovators,
into a world of standard packages with
IT support glueing them together. Seat
ticketing had to talk to iSAMS. iSAMS
had to talk to examination boards,
and so on. The floating hotel that is
Shrewsbury had to provide internetbased
resources without compromising
on security. And backend provision was
changing. Real servers became software
packages running on 19” rackmounts,
and the creation of a webserver involves
just a few keypresses on one of the host
machines.
As things matured, the virtual classroom
became a reality. Just in time for
the COVID pandemic, Shrewsbury’s
adoption of e-learning enabled the
School to function in some manner,
and emerge more or less intact. Indeed,
a VLE (virtual learning environment)
probably saved the School during
the COVID pandemic. But that is for
someone else to judge.
1. Local Area Network – a network occupying one room or building.
2. If mt@shrewsbury.org.uk was the email address, mt taught the set.
3. The set of rules for communicating between computers. TCP/IP was a complex set which was difficult to implement. BBCs used a simple but proprietary
protocol. PCs ran the full TCP/IP – so we judged that to be the better bet.
4. DMZ = central zone, flanked by a secure fence (a firewall) through which few are allowed. All the important servers go in the DMZ with access to them
controlled by other machines.
5. VPN = Virtual Private Network. Multiple networks can run privately over a single physical connection, thanks to the wonder of encryption. For instance, we
would run House staff in a different network to boys.
6. A unique number attached to a network card, allowing us to identify the card and hence the PC and hence the user. Or so we thought.
7. SMB = Microsoft’s file sharing server system. The servers are generally referred to as SAMBA machines,
8. Structured Query Language. Used to access data in a database. Nearly everything, these days, is held in a database.