Almost Internet with SLiRP and PPP
The pppd package comes with a utility program called chat which performs “expect-send” scripts for dialing modems, performing automated logins, etc. chat is located in pppd-2.1.2d/chat/. The steps for compiling and installing chat are essentially the same as for pppd: copy the makefile, edit to suit your system, make, and then make install as the superuser. The chat manual page, however, needs to be installed by hand; use
install -m 0444 -o root -g man chat.8 /usr/man/man8/
to do this.
Now is a good time to read the manual page for pppd. While it is rather long, the manual page contains some information critical to understanding how to set up pppd, including explanations of several scripts called by pppd. There are several steps involved in properly configuring pppd, and a few more in making it convenient to use:
Creating the system-wide pppd configuration file /etc/ppp/options.
Modifying the network configuration files to work with a PPP connection.
Creating the scripts /etc/ppp/ip-up and /etc/ppp/ip-down to perform any needed actions when the PPP link becomes active and before it is closed, respectively.
Configuring the system logging facility so that messages from pppd are written to the system logs.
Creating scripts to start and stop pppd gracefully.
The system-wide configuration file, /etc/ppp/options, is the most important thing to get right for pppd to work. The file must exist and be readable by the root user, even if you don't plan to store configuration information in it—otherwise, pppd won't start. Unfortunately, there are so many possible options to configure for pppd that it's difficult to build a configuration file from scratch. I have put together an options file template for pppd, which includes each configurable option and explanatory text taken directly from the pppd manual page, and made it freely available for anonymous FTP (see References for locations). I recommend fetching the pppopt.tgz package to use as a starting point for configuration.
A configuration file for pppd looks like this:
## /etc/ppp/options -- config file for pppd # async character map -- 32-bit hex; each bit # is a character that needs to be escaped for # pppd to receive it. 0x00000001 represents # "<\>x00", and 0x80000000 represents "<\>x1f". asyncmap 0 # Use hardware flow control (i.e. RTS/CTS) to # control the flow of data on the serial port. crtscts # Add a default route to the system routing # tables, using the peer as the gateway, when # IPCP negotiation is successfully completed. # This entry is removed when the PPP connection # is broken. defaultroute # Set the MRU [Maximum Receive Unit] value to <n> # for negotiation. pppd will ask the peer to send # packets of no more than <n> bytes. The minimum # MRU value is 128. The default MRU value is 1500. # A value of 296 is recommended for slow links # (40 bytes for TCP/IP header + 256 bytes of data) mru 552 # Disables the default behaviour when no local IP # address is specified, which is to determine (if # possible) the local IP address from the # hostname. With this option, the peer will have # to supply the local IP address during IPCP # negotiation (unless it is specified explicitly on # the command line or in an options file). noipdefault
This file assumes that the modem is set to use hardware flow control (crtscts), that the link between the local machine and the remote one is 8-bit-clean (asyncmap 0), and that the remote machine will tell pppd what the local machine's IP address is (noipdefault). It also tells pppd to add a “default route” to the system routing tables (defaultroute), which is generally what we want for a dial-up Internet connection, and sets the “maximum receive unit”, the largest PPP packet that pppd will accept, to 552 (mru 552).
If you want to use software flow control instead of hardware flow control for your modem, you can use xonxoff instead of crtscts. You also need to add the XON and XOFF characters to the asyncmap option, as follows: the number following asyncmap is a 32-bit hexadecimal number, where each bit represents a character between 0x00 (^@) and 0x1f (^_) which must be “escaped”, or sent as a two-byte sequence to avoid getting swallowed or munged in transmission; asyncmap 000a0000 escapes characters 0x13 (^S) and 0x11 (^Q), the XON/XOFF characters. You will also need to add this asyncmap setting to your SLiRP configuration file on the remote host.
The network configuration files on your Linux system which you need to modify or check are:
/etc/rc.d/rc.inet1 or /etc/rc.net, the network configuration script (it may be called something slightly different, depending on your distribution)
/etc/hosts, the hostname-to-address configuration file
/etc/resolv.conf, the resolver configuration file
Configuration of these files is discussed in detail in the README.linux file that comes with pppd under the heading “General Network Configuration”; however, a few items are important for using pppd with SLiRP:
In /etc/hosts, use the address `10.0.2.15' as the address for your Linux machine; this is the address SLiRP uses by default. For example, my own machine is called “zephyr”, in the fictitious domain “earth”, and the following line appears in my host table after the loopback entry:
10.0.2.15 zephyr.earth zephyr
In order to fill in the nameserver part of /etc/resolv.conf, you need to know the address of the nameserver for the remote host. There are three ways to find out this information, in order from least to most effort:
(1) Use the command nslookup, which will print the name and numeric address of the default nameserver (use exit to exit nslookup);
(2) Read the remote resolver configuration file using the command cat /etc/resolv.conf--it should have nameserver entries just like the ones you need; or
(3) Ask the system administrator, who may or may not be willing to give you that information.
You may wish to perform certain actions when the PPP link opens and to perform others when the PPP link closes down; you can put such actions in scripts called /etc/ppp/ip-up and /etc/ppp/ip-down. For instance, I have configured smail (my mail delivery agent) to send outgoing mail to my Internet account provider, which is only available when my PPP link is up. In my ip-up script, I have a command to send any queued outgoing mail along to the smart-host for delivery.
#!/bin/sh # # /etc/ppp/ip-up -- do net-stuff when ppp is up # send queued outgoing mail over new net connection /usr/sbin/runq
The ip-up and ip-down programs do not have to be shell scripts—they could just as easily be written in Perl, Tcl, or any other scripting language. However, the scripts should be executable, i.e. they should have execute permission set (using
Do not break up the following line:
chmod 0755 /etc/ppp/ip-up /etc/ppp/ip-down
and the first line of the script should be of the format #!path-to-program, containing the complete path to the program that should run the script (e.g., #!/bin/sh for a Bourne shell script, or #!/usr/local/bin/perl for Perl).
pppd sends messages and some debugging information to the system logging facility syslogd. You may wish to configure syslogd so that those messages get logged to a separate log file; to do this you need to become the superuser and modify the syslogd configuration file /etc/syslog.conf. pppd logs to the “daemon” facility, so we add the following line to syslog.conf:
# Log daemon-related messages in a special place daemon.* /var/log/daemon.log
You should put the daemon log in the same place as your other system logs; the Linux Filesystem Standard recommends /var/log. In order to get syslogd to re-read its configuration file, send it a hangup signal using the command kill -HUP pid, where pid is the numeric process id for syslogd as shown in a listing made by a ps ax command. Alternately, use killall -HUP syslogd.
Since it can be a bit tedious trying to start and stop pppd from the command line, I recommend creating two executable scripts called ppp-on and ppp-off. The pppd package comes with sample scripts in pppd-2.1.2d/chat, which you may wish to use as a guide. Simple versions of each are shown in Figure 1 and Figure 2. You should probably install the scripts in the same place as you install pppd (for my system, /usr/local/ppp/bin).
Figure 1. Example ppp-on Script
Figure 2. Example ppp-off 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!
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- 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