The Joy (and Agony) of SLIP
Have you ever wanted to connect your computer to a network? Perhaps you have two computers that you want to run Mosaic, ftp, or X11 between? Do you want to let your friends experience the full power of your magnificent new Linux box? SLIP is one way you can do all these things.
by Warren Baird
SLIP (Serial Line Internet Protocol) is a protocol that allows you to make a TCP/IP connection over a serial line. TCP/IP stands for Transmission Control Protocol/Internet Protocol, and is the protocol used on the Internet and on most local ethernets. Many common Unix programs (like X11, Mosaic, gopher, IRC, talk, telnet and ftp) use TCP/IP to communicate. If you want to use programs like this to talk to the rest of the world over the Internet, or if you want to connect two (or more) local machines, SLIP is a good option.
There are actually two variants of SLIP: normal SLIP, and CSLIP (which stands for Compressed SLIP). CSLIP compresses various TCP/IP headers to give a higher throughput on a serial line. (Note: CSLIP doesn't compress the data that is being transmitted, just the headers added by TCP/IP.) Unfortunately not all systems support it. Even with CSLIP, the throughput on a serial line is quite low compared to ethernet and other Local Area Networks (LANs). It's possible to run high bandwidth applications like Mosaic and xv over a SLIP link, but the response times may be quite low.
One of the most common uses of SLIP is to connect to a commercial Internet provider. There are many companies that provide full access to the Internet by allowing you to make a SLIP connection using a modem.
Another use of SLIP is to connect two or more machines using a null-modem cable. Since SLIP is implemented for many different platforms, you can connect your Linux box to many different types of systems. For example, I have an Amiga 2000 connected to my 386 running Linux 1.0.8.
If you are really ambitious, you can even set up your Linux box as a SLIP server. You could do this to give your friends access to your machine, or as part of a BBS setup.
Configuring something like SLIP under Unix is always very dependent on the flavor and version of Unix that you are running. The details given here are for the Slackware 1.2.0 (Linux 1.0.8) distribution. The exact details may vary somewhat with other versions of Linux and other distributions.
There is a whole host (no pun intended) of files that control the behavior of a Unix system, and a number of them need to be modified to set up SLIP.
Looking up host names: /etc/hosts, /etc/resolv.conf, and /etc/host.conf
The /etc/hosts file maps hostnames (for example acme.gadgets.com) to IP addresses (for example 18.104.22.168). If you are using SLIP to connect two local machines, your /etc/hosts file only needs to contain the hostnames and IP addresses of your two machines. If you are connected to a larger network, but talk to only a few sites, you can put their names and IP addresses in your /etc/hosts file.
If you are connecting to many hosts (or using a program like Mosaic that connects to many hosts), you'll need to tell your system who it should ask to find IP addresses for unknown hostnames. There are systems called nameservers that will lookup an IP address for a given hostname. The /etc/resolv.conf file tells your system which nameserver(s) to use. It also tells your system what your domain name is. The domain name is your full hostname with the machine name removed—for example, if your hostname is acme.gadgets.com, your domain name would be gadgets.com.
If your domain name is gadgets.com, and you have a nameserver at the IP address 22.214.171.124, your /etc/resolve.conf file could read:
domain gadgets.com nameserver 126.96.36.199
It's possible to list multiple nameservers in a resolve.conf file. The /etc/host.conf file tells the system what order it should use to lookup hostnames. Normally this file contains
order hosts,bind multi on
which tells the system to check the /etc/hosts file first, and then to try any nameservers it knows about.
The names of the Internet startup files vary even between different Linux distributions. On most Linux systems the files used are /etc/rc.d/rc.inet1 and /etc/rc.d/rc.inet2. Whichever startup file is used, there are a number of daemons that must be running for any TCP/IP program to work. The NET-2 HOWTO describes which daemons are available, and what they do. Minimally, you need to have the inetd daemon running. The inetd daemon coordinates the startup of many other TCP/IP daemons.
Additionally, if you are setting up a permanent link to another computer over a dedicated line, you may want to actually initialize the SLIP link in the startup files.
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!
- Stunnel Security for Oracle
- SourceClear Open
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Tech Tip: Really Simple HTTP Server with Python
- Google's SwiftShader Released
- 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