Cooking with Linux - L'Intranet Originale
That's right, it's completely nongraphical, but there is color, mon ami. Why? Well, François, I suppose I'm feeling a bit nostalgic. When I read that this issue's theme would be intranets, it started me thinking about the whole idea of an intranet, literally an internal network—a private little universe, if you will, for a specific set of users. Usually, we think of a business or an organization making use of this, but intranets also are perfect for hobby or user groups. When we talk about intranets, we tend to think of Web contact management systems and portals that perform these functions.
Quoi? The text-only screen? That's easy. The original intranet existed long before we all started getting on the Internet, mon ami, and communication was nongraphical. Mon Dieu, why are we still talking? Our guests are already here. Welcome, mes amis, make yourselves comfortable while François brings you your wine. To the wine cellar, François. Please bring back the 2003 Coastal Sauvignon Blanc. Vite!
I was just telling François about the original intranets, mes amis. Way back when I was just getting out of my teens, I started running one of these original intranets on an old Commodore 64. They were called bulletin board systems, or BBSes. In fact, I wrote and ran my own BBS all those years ago. The one I operated had one phone line, which meant only one user could dial in at a time. This was a non-networked system, but it was an intranet and at its peak, 40 or 50 users took advantage of it. That little trip down memory lane is why I put together a menu of BBS programs.
You might think that in this heavily graphical age, no one uses or continues to work on text-style BBS programs. In truth, many BBSes still are in operation, and developers continue to work on and develop the programs.
The first item on tonight's menu is Bryan Burns' NexusChat. NexusChat, or NChat, is an excellent BBS-style program that provides different user levels, multiple rooms, private and group chats, e-mail messaging, on-line configuration, on-line help and a whole lot more. Furthermore, you don't need to be root to run NexusChat, nor do you need to be root to install it. Start by creating a directory where you would like the chat server to be installed. For instance, I created a directory called nexuschat in my home directory. The next step is to extract the source package:
tar -xzvf nchat-3.31.tar.gz cd nchat-3.31 ./setup.sh
The questions you have to answer are pretty basic, and you can accept the defaults, with a few exceptions. When asked where you would like the binaries installed, indicate the chat directory you created earlier. The base data directory, which defaults to /home/nchat/etc, now can be an etc subdirectory wherever you chose to install it. Next, you are asked for the number of ports. That's the maximum number of people who can connect to your chat server at any given time. The default here is 15. When you have answered this last question, it's time to type make. After a few seconds of compiling, the final step is to create the user database. By default, you should create 999 slots for possible users.
That's it; there's no install here. The final step involves moving the etc directory to its final location manually. You also need to do the same for the nchat and userdb binaries. In my case, I chose to run the server in /home/marcel/nexuschat, so I executed the following commands:
mv etc /home/marcel/nexuschat mv nchat /home/marcel/nexuschat mv userdb /home/marcel/nexuschat
Switch to your NexusChat directory and prime the user database with userdb -z -s 999. Aside from prepping the database, you need to create the 000 user with a password of root. To start the server, which runs on port 4000 by default, simply type /path_to/nchat. Now, from another terminal, connect to your chat server and log in as 000:
telnet your_server 4000
One of the first things you need to do once connected is change your password. You do that by typing /passwd topsecret where topsecret is the new password you choose. Once you are connected and chatting, a number of different commands are at your disposal. As with the password change command, these all begin with a slash character. To get a list of available commands, type /?. If, for some strange reason, you can't see what you are typing, type /echo.
At this point, guests also can log in. All they have to do is press Enter, and they automatically are entered as a guest. They can type NEW to register themselves as a user on the system, but the SysOp has to confirm their registration before they can log in. At this point, they can change their handles and chat with a limited set of commands. The administrator—that is, the person running the nchat program—can add permanent users or activate a self-registered user while logged in by calling up the user editor; use the /ue username command. You also can do this from the command line with userdb, the other binary that was installed. To add a user from the NexusChat directory, then, you would enter the following:
./userdb -a user -u -l 003 -h Francois -p 123 -t 3600
You are adding a user-level account (-a), there is also sysop; updating the user database (-u); creating user number 003 (-l); assigning the user a handle of Francois (-h); assigning a password of 123 (-p); and setting a session timeout of 3600 seconds (-t). If you simply type userdb without any options, a list of all the various options is returned.
I mentioned that the default port number was 4000. This and a few other parameters can be changed by editing the etc/nchatrc file. You likely want to change chat_name to something of your choosing, as this is the BBS' name. Some parameters, such as ask_ansi = true, are commented out. Also, although most terminals can handle the ANSI colors without a problem, it might be nice to offer that choice to users when they log on.
Some other interesting files are located in the etc directory. The nc_login file, for example, is what the user sees upon logging in, along with an equivalent nc_ansi_login, and nc_motd is the message of the day.
NexusChat is a lot of fun and easy to run, with minimal administrative issues. It's also quite flexible and offers simple user and chat room creation options. There's even a basic e-mail function so you can leave private messages for users that aren't currently on-line. Should you decided to try NexusChat, it's worth checking out the NexusChat Web site for a comprehensive list of its many features (see the on-line Resources).
While François refills your glasses, let's look at another example of the venerable BBS. Some programs offer more sophisticated features than NexusChat does, such as full message facilities, complex room creation—some for messaging, others just for chatting—statistical information, world clocks and calendars and more. One such BBS is Walter de Jong's bbs100.
To get bbs100 ready to use, you need to build it from source, which you can get from the bbs100 Web site (see Resources). Compiling and installing the program is fairly easy, but the steps might seem a bit strange:
tar -xzvf bbs100-2.1.tar.gz cd bbs100-2.1/src ./configure --prefix=/home/bbs100 make dep make make install
In particular, notice the prefix above. It's important not to use the /usr/local default, because the BBS needs to be able to write in various directories under that prefix, and permissions may not allow it under /usr/local. I also didn't do a make install as root, because it isn't necessary. That said, you need to make sure your login has access to the directory in which you are trying to install. I created a /home/bbs100 directory for this particular BBS.
When you are done with the installation, switch to the installation directory, in my case /home/bbs100, and open etc/param in your favorite editor. A few settings here should be changed right away, such as the ones that include the BBS name, the port on which you want to run the program and the base directory for the installation, mostly for confirmation:
bbs_name The Cellar port_number 12345 basedir /home/bbs100
Before we move on, I suggest you take some time to become familiar with the various files in the etc directory. They include welcome screens, the message of the day, help files, system rules displayed on first login and a lot of other interesting things.
You're almost there. Because we made Francois the SysOp, we also need to give him a password to log in. From the directory where you installed the BBS, type bin/mkpasswd SysOP_Name; you then are asked for a passpharase for that user:
bin/mkpasswd Francois bbs100 2.1 mkpasswd by Walter de Jong <email@example.com> (C) 2004 Enter password: Enter it again (for verification): OIGxutxGpuTowzw2AgMXZRkCNk
The last line is the SysOp's encrypted password. To let the BBS know about it, edit etc/su_passwd and enter the SysOp's name followed by a colon, followed by the encrypted passphrase:
To start the BBS, simply type /home/bbs100/bin/bbs start. Once the dæmon is running, connect from a terminal window by doing a telnet to the port you defined:
telnet your_system 12345
To change to the BBS equivalent of the superuser, or root, press the $ hot key. In this case, the superuser is known as the SysOp, or system operator. Only the person with his or her handle in the etc/su_passwd file has this hot key at his or her disposal. In all other cases, a nice calendar is displayed showing times in various worldwide locations. Once you are SysOp, you have access to a number of additional commands; simply press Ctrl-S to enter the SysOP menu. Once you are the SysOp, you have the option of configuring various system parameters, creating rooms (message as well as live chat rooms) and dealing with pesky users if need be.
It may take some getting used to, but the BBS concept is powerful and maybe a little addictive. Here's another reason to consider it. With six users on-line, my total memory usage, including the running bbs100 program, was 66,917 bytes. As you can see, mes amis, being smaller and simple surely had its advantages.
As we marvel at the popularity of instant messaging and cell phone text messaging, let's remember that the roots of these technologies go back a long time. To prove my point, I'm going to end this with a little trip down memory lane. Once upon a time, there was a command called write and another called mesg. The mesg command allowed you to turn on your message facility like this:
Simply stated, you were allowing others to send you messages. Now, log on to another terminal session and turn on message there as well. Let's pretend that I am logged in as marcel on one terminal and François is logged in as francois at another. He could open a chat session with me by doing this:
write marcel /dev/pts/16
He then would be able to start writing whatever he wanted, until he pressed Ctrl-D to finish the chat session. On my terminal session, I would see the following:
[marcel@francois marcel]$ Message from firstname.lastname@example.org on pts/14 at 19:30 ... Hello there, Chef! Have you decided what kind of wine we will be serving tonight?
As the saying goes, Plus ï¿½ change, plus c'est la mï¿½e chose.
It appears, mes amis, that closing time is once again upon us. Take your time though, and finish your conversations. In the world of text, it somehow feels easy to sit back and enjoy a glass of wine without rushing. Therefore, mes amis, let us all drink to one another's health. A votre santé Bon appétit!
Resources for this article: /article/8198.
Marcel Gagné is an award-winning writer living in Mississauga, Ontario. He is the author of Moving to the Linux Business Desktop (ISBN 0-131-42192-1), his third book from Addison-Wesley. He also is a pilot, was a Top-40 disc jockey, writes science fiction and fantasy and folds a mean Origami T-Rex. He can be reached at email@example.com. You can discover a lot of other things, including great WINE links, from his Web site at www.marcelgagne.com.
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!
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server
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