The 19th Century Meets the 21st
At the start of the project, I had one overriding goal: keep the architecture as simple as possible. I could not guarantee a networking wizard would be available when things failed. In fact, our backup system administrator is a 12-year old resident who knows little about computers; I figured she would be easier to train than most adults. Knowing I was going to have to write thorough documentation about everything I implemented helped me stick to my goal.
We knew Linux could support multiple Ethernet interfaces. We were not sure where to find a card with Linux drivers that could interface with our DSU. A bit of Net research turned up a Canadian vendor, Sangoma Technologies, that seemed to be selling exactly what we needed. Five minutes on the phone with one of their Linux guys convinced me their WAN pipe product would do the job. At $550, it was the most expensive piece of hardware I had to buy, and it certainly beat Cisco's “cheap” solution.
I now had all the pieces: a frame-relay line from the outside, a DSU, a router, a hub, a general purpose computer, wires and a willing alpha tester. I just had to work out the details.
We originally planned to isolate each apartment behind an Ethernet interface. Of course, that seemed ridiculous for those with a single Windows 95 box. We then considered putting all the single machine apartments on their own segment. This presented an evolutionary problem. Whenever anyone bought a second machine, we would have to change IP addresses, physical connectivity, etc. We were stuck between over- and under-engineering the network, until my neighbor remembered some work he'd done earlier for a client in Atlanta.
He remembered Linux supports something called Ethernet aliasing. This allows a single interface to support multiple networks. For example, a single Ethernet card can be configured to support ten apartments, each of which is assigned its own subnet. This turned out to be the perfect compromise. We could logically isolate each apartment without having to use many Ethernet cards and several computers.
If an apartment grows into needing more thorough isolation, we can upgrade it to its own Ethernet board! By the time all available slots are used in our current 486, it will have to be replaced in order to deal with the Y2K issue. By then, maybe the router vendors will be selling solutions with more down-to-earth prices.
When I first began discussing the network idea with other residents, security seemed to be at the top of their list of concerns.
We worked out a few security schemes using proxy and masquerading facilities. Whatever we ultimately decided to do had to be configurable on an interface-by-interface basis. I personally wanted access to my computers from the outside world. Luckily, Linux supports that sort of granular security.
One day, I happened to mention the various options to a relatively computer-savvy neighbor who runs a local area network in her apartment. She was horrified that I would consider implementing a security scheme at the building level. She wanted control over her own security so that she could access her machines from anywhere on the Net. After a bit of discussion, we realized the original requests for high security were all from people who used Windows 95 to dial up through AOL.
It turns out the concerns were the result of alarmist articles in the local papers—security threat articles fail to put the subject in perspective. The least savvy are most easily frightened, even though they are least at risk since they use operating systems with few services that can be abused.
Having come to that realization and remembering our “keep it simple” goal, we decided to leave security up to the individual apartment. After all, AOL does not provide any special security to the lone PC connecting through its network.
We toyed with the idea of allowing everyone to register their own domains, but finally decided against it as this would have created too much work. Instead, we registered a domain for our building, 8OldFulton.com, which is related to our physical address. This is one of the few cases in which I think geographic addressing of any kind makes sense. Given the choices we made, the administrative burden of adding a machine or cluster of machines is relatively light.
Mail service is not yet settled. At the moment, we run a POP3 server, because it is essentially administration-free. POP3 is not, however, particularly friendly for people who travel a lot or use multiple computers. Therefore, it is very likely I will eventually bring up an IMAP4 or web-based mail server.
Anyone who wants a more flexible e-mail system immediately in place needs to set up and maintain their own.
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- Nice article, thanks for the
1 hour 4 min ago
- I once had a better way I
6 hours 50 min ago
- Not only you I too assumed
7 hours 8 min ago
- another very interesting
9 hours 1 min ago
- Reply to comment | Linux Journal
10 hours 54 min ago
- Reply to comment | Linux Journal
17 hours 48 min ago
- Reply to comment | Linux Journal
18 hours 4 min ago
- Favorite (and easily brute-forced) pw's
19 hours 55 min ago
- Have you tried Boxen? It's a
1 day 1 hour ago
- seo services in india
1 day 6 hours ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?