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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- Tech Tip: Really Simple HTTP Server with Python
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- SuperTuxKart 0.9.2 Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide