Eagles BBS
It all started as a port of Pirates Bulletin Board System (PBBS) version 1.6 to ESIX/System V. Pirates BBS was written by Ed Luke at Mississippi State University in the summer of 1989, and earned its place in Internet legend through the now-defunct Mars Hotel BBS. Two friends from high school, then students at the University of Southern Mississippi (which is my alma mater as well), generated enough interest in an Internet BBS to get space on a machine in the Computer Science Department. Together we ported Pirates, which was strictly BSD code at the time, to ESIX. The Eagle's Nest BBS was born April 14, 1992.
It wasn't easy or pretty, as any early user of the Eagle's Nest will tell you, but it eventually worked. Along the way I added a lot of features from other BBSes that Pirates 1.6 didn't have, brought in things from later Pirates revisions, and even had a few original ideas. It wasn't meant to be anything but a simple PBBS port, but people started taking an interest in our “enhanced Pirates”, so we gave it our own name—Eagles BBS—in honor of the Eagle's Nest, and of our school's mascot from which that name is derived.
We released Eagles BBS 1.0 in August 1992, and I've updated it four times since then. My partners have since dropped out of the project. Thanks to a lot of gracious folks across the Net, I received ports of it to quite a few other operating systems. None of these received more than casual attention, until we discovered Linux. Before I get into that, I should give a little technical information about the software itself.
Eagles BBS is a self-contained, multifunction bulletin board package that is accessed by logging in to a special account, either through telnet, dial-in, or a terminal. Three executables comprise the EBBS system: bbsrf, bbs, and bbs.chatd.
bbsrf is a special setuid root login shell. A user “bbs” is placed in /etc/passwd with bbsrf as its login shell. bbsrf optionally erases the login from /etc/utmp, making it invisible to the “finger” and “who” commands. It then does a chroot to the bbs home directory, does a setuid back to “bbs”, and execs the bbs program.
The chroot is done for security purposes. With it, anyone who might break out of the bbs program into a shell will only have access to the bbs home directory, not the rest of the host system. Because of the chroot, the BBS is completely self-contained underneath the bbs account's home directory, except for the record in /etc/passwd. All files needed by the BBS at run time are copied under ~bbs; for example the /etc/termcap file is copied to ~bbs/etc, the shared C library is copied to ~bbs/lib, and so on. This is a major portability headache. More on this later.
The bbs program does most of the work. First it prompts the user for a userid and password, which are validated by a lookup in the ~bbs/.PASSWDS file. This is much like how the standard system login program works, except ~bbs/.PASSWDS is a binary file. Once logged in, the user navigates through a series of menus accessing the features of the BBS.
The menu system is full-screen, and uses the terminal capability database (~bbs/etc/termcap) for efficient manipulation of the terminal. EBBS does not use
libcurses but a stripped-down, simplified curses look-alike dating from the Pirates days. Because the user is usually coming in through telnet, the BBS cannot always tell what terminal type the user has; there is a menu option for the user to specify this, however. The menu system is hierarchical; from the top level Main Menu one can access submenus, such as the Talk Menu, Xyz Menu, File Menu, and Mail Menu. The functions available from the menus can be roughly divided into seven categories, which I'll briefly describe:
Sending/reading mail: Mail may be sent to other users of the BBS. In addition, a facility for forwarding BBS mail (and posts) to a remote Internet mailbox is included. Receiving mail from Internet is not supported; since users do not have real accounts insofar as the operating system is concerned, this would be a little tricky.
Posting/reading messages: Up to 80 boards may be set up by the operator on which users may post public messages. The operator may restrict boards to certain groups of users with permission masks. The BBS boards do not interface with outside message services like Usenet or Fido.
File upload/download: The BBS has a facility for file uploading and downloading with serial-line protocols like Zmodem and Kermit, allowing files to be transferred straight from home computers to the BBS. Using these protocols across a slow Internet link usually does not work very well, however. Most sites also offer ftp access to their file bases since it's more suited to long-distance network transfers.
Talk: An emulation of the Unix “talk” utility is available, allowing one-on-one talk sessions with other BBS users. The talk facility does not allow connections to remote systems like Unix talk does.
Chat: A local chat system is built into the BBS. Up to four separate rooms may be configured. A chat daemon (bbs.chatd, the third program making up the BBS) process is spawned when the first user enters a room, and serves to relay messages to all users in the room. A number of IRC-like features have been hacked into the chat facility, like private messages, actions, and commands to show who's logged on.
User utilities: For setting things like your nickname (not login userid), terminal type, and address for mail/post forwarding. These are on the Xyz Menu.
Administrator utilities: These are only accessible by privileged users. This includes things like account and board creation and removal, setting permission flags on accounts, mail cleans, and welcome screen editing.
As you can see, EBBS, like its Pirates predecessor, stands on its own for the most part—hooks to other services are few and far between. Much of this is necessary because of the chroot. Some sites have integrated Internet Relay Chat clients into their BBSes, but even then the built-in chat system is quite popular. EBBS seems to be popular among computing neophytes because of the simple menu system and builtin editor. On the same token, power users sometimes get frustrated by its limitations.
The isolated nature of a PBBS or EBBS system encourages some interesting relationships among its regular users, especially after a system has been around for a while. Some of the things that go on would surprise even the most ardent soap opera fan! I'll leave that topic open for another article, though.
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.
Sponsored by AMD
If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.
Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.
Sponsored by ActiveState
| Speed Up Your Web Site with Varnish | Jun 19, 2013 |
| Non-Linux FOSS: libnotify, OS X Style | Jun 18, 2013 |
| Containers—Not Virtual Machines—Are the Future Cloud | Jun 17, 2013 |
| Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer | Jun 12, 2013 |
| Weechat, Irssi's Little Brother | Jun 11, 2013 |
| One Tail Just Isn't Enough | Jun 07, 2013 |
- Speed Up Your Web Site with Varnish
- Containers—Not Virtual Machines—Are the Future Cloud
- Non-Linux FOSS: libnotify, OS X Style
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Linux Systems Administrator
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- Android's Limits
- Weechat, Irssi's Little Brother
Featured Jobs
| Linux Systems Administrator | Houston and Austin, Texas | Host Gator |
| Senior Perl Developer | Austin, Texas | Host Gator |
| Technical Support Rep | Houston and Austin, Texas | Host Gator |
| UX Designer | Austin, Texas | Host Gator |
| Web & UI Developer (JavaScript & j Query) | Austin, Texas | Host Gator |
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?




1 hour 6 min ago
4 hours 37 min ago
7 hours 31 min ago
7 hours 56 min ago
10 hours 25 min ago
10 hours 58 min ago
10 hours 59 min ago
11 hours 36 sec ago
11 hours 2 min ago
11 hours 3 min ago