Ghosting onto the Net
Recently I got the urge to tinker with managing my network at home in order to get some experience with Unix and heterogeneous network management. I have three Windows boxes (two with Windows 95 and one with Windows 3.1) hooked up to a Linux server. I use the LinTel box as both a local file server and as a gateway linking my home network to the Internet.
The software I use to handle the file server tasks is SAMBA. My primary reference for setting up SAMBA was the excellent article on the subject in the July, 1996 issue of Linux Journal.
In picking a dial-up program, I kept two requirements in mind:
I didn't want to manually log on to my ISP each time I wanted access to the Internet.
I didn't want my LinTel box to call up my ISP on startup and then remain connected until I shut it down. I wanted to be considerate of my ISP's other clients by not monopolizing a phone line.
A program written by Eric Schenk, called diald, satisfied both these requirements. I use diald to connect to my ISP whenever I have traffic destined for the Internet. It also automatically disconnects from my ISP if there is no traffic for a specified interval.
I work for various companies with access to the Net, and while at work, I like to access my home Linux server through the Net from time to time—just in case I find something neat during a lunch break that I want to tinker with at home. So I set up my server to connect to the Net at various random intervals between 15 and 60 minutes, loiter around for five minutes and disconnect if there is no traffic. While my server is connected I can download anything I wish. I call this process ghosting.
These are the steps I went through to get ghosting to work. Depending on whether you already have Linux installed and what flavor it is, you may be able to skip some steps.
The first thing I did was acquire Red Hat 4.0 from Red Hat Software, http://www.redhat.com/. I had heard good things about Red Hat and liked their “Red Hat Package Manager” for handling software bug fixes and upgrades—it sure makes life easier. I installed Red Hat by following the directions given during the install process.
Next, I downloaded the latest version of the kernel available at that time, 2.0.29, from sunsite.unc.edu, and configured my new kernel using hardware specific settings.
Another necessity for ghosting is IP masquerading. I found three good sources of information on IP masquerading:
The most definitive is the IP-Masquerading Resource home page at http://www.wwonline.com/~achau/ipmasq/.
The IP-Masquerading Mini-HOWTO, probably available at your favorite Linux site on the Net.
The last is the IP masquerading article in the July, 1996 Issue of Linux Journal. I downloaded the latest IP masquerading patch for kernel 2.0.28 and higher from the IP-Masquerading Resource home page, and it worked fine with my 2.0.29 kernel. Again, all I had to do was follow the instructions to reconfigure the kernel using the make menuconfig method. Here are the pertinent settings for IP masquerading to work:
Under Code Maturity Level Options, turn on “Prompt for development and/or incomplete code/drivers”. (The IP masquerading code is still considered alpha code.)
Under Networking Options, turn on “Network firewalls”, “Network aliasing”, “TCP/IP networking”, “IP forwarding/gatewaying”, “IP multicasting”, “IP firewalling”, “IP accounting”, “IP masquerading (EXPERIMENTAL)” and “IP tunneling”.
After configuring the rest of the kernel, I just continued following instructions to build it. I recommend doing a make zdisk and making sure the system boots fine from floppy before doing a make zlilo. That way the old kernel doesn't get accidently blown away. My make procedure is:
make dep make config make -j5 zdisk make -j5 modules make modules_install
I then reboot from the floppy and keep an eye on the startup information. With a successful reboot, go back into the Linux source directory and do a make zlilo. The -j5 switch causes make to spawn up to five compiles simultaneously. This method of compilation speeds up the build process tremendously.
After installing Red Hat I set up the point-to-point protocol daemon (pppd); this allows my Linux server to communicate with the Internet. The ppp daemon came with the Red Hat package, and installs automatically when a networking package is selected.
First, I set up a configuration file named /etc/ppp/options, then created a chat script to tell the ppp daemon how to communicate with my ISP. The configuration file I used looks like this:
modem /dev/cua0 38400 asyncmap 0 defaultroute
The man page for the ppp daemon explains these lines in detail. The default configuration file that comes with Red Hat should suit your purposes. The only line to be concerned about is /dev/cua0—this line tells the ppp daemon where to find your modem.
Before pppd can be used to communicate to the Internet, you have to dial and connect to your ISP. This usually involves a process called handshaking, implemented by a program called chat. A chat script sends the chat program the instructions for logging into your ISP. A chat script is basically a series of wait and send strings. Red Hat provides a network configuration tool that runs under X-Windows and can be used to create and test chat scripts. I had a chat script called /etc/sysconfig/network-scripts/chat-ppp0 (see Listing 1[footnote]). I symbolically linked this script into my /etc/ppp subdirectory using the following commands:
cd /etc/ppp ln -s /etc/sysconfig/network-scripts/chat-ppp0
You will need to modify my chat script by changing the phone number, username and password responses to match your own. You may also need to modify the line ppp default depending on the requirements of your ISP—contact your ISP for that information.
Now, there are some things I want the system to do right after a successful connect to, or disconnect from, the Internet. Fortunately, pppd has a couple of features that make this easy. When the ppp link comes up, the daemon checks for the existence of a script called /etc/ppp/ip-up. If this script exists, ppp daemon invokes it with the specified connection parameters. My version of this script appears in Listing 2—notice the comments at the top of the script indicate the parameters pppd passes to the script.
When the ppp link goes down, the ppp daemon checks for the existence of a file called /etc/ppp/ip-down. If this file exists, it is invoked when the ppp link is terminated. The contents of my script are shown in Listing 3. This script mainly does some cleanup—undoing what I did in the ip-up script.
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!
- Google's SwiftShader Released
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Interview with Patrick Volkerding
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Doing for User Space What We Did for Kernel Space
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