A 10-Minute Guide for Using PPP to Connect Linux to the Internet
The name resolver is a small piece of software within the standard Linux library that allows automatic conversion of a host name, e.g., sunsite.unc.edu, into an IP address, e.g., 126.96.36.199.
Configuration of the name resolver is easy; there is only one file to change. You will almost certainly already have this file on your machine, but you will need to configure the correct address for the nameserver. Assuming your ISP supplied you with a nameserver address of 188.8.131.52 then your /etc/resolv.conf file should have a line that says:
To start the PPP link, all you need to do is execute the following command as root:
The pppd program will start and will search for its options in the standard locations. It will find our options file at /etc/ppp/options and read each line. When it has finished processing all available options, it will open the specified serial device, create a lock file to prevent other programs from trying to use it, and then attempt to run the connect program and to execute the /etc/ppp/net-connect script. The net-connect script will execute the chat program telling it that it should take its parameters from the /etc/ppp/net-chat file. The chat program starts, reads each of the lines from the net-chat file, waits for the strings, and sends the responses it has been given. Provided the chat program did not ABORT then control is passed back to the pppd program, which will then switch the line into PPP mode and create a PPP network device. The pppd program will automatically begin negotiation of some configuration details with the PPP program at the other end of the link. The most important of these details is the IP address you will use. The pppd program will create a ppp network device ppp0 and then configure it with the details it obtained from the other program. Finally, the pppd program will configure your routing table with a route that tells your Linux machine it should send datagrams to the PPP link, if it doesn't have anywhere better to send them. The pppd program will then sit happily in the background until either the line fails, the remote end closes the connection or you terminate it locally.
Okay, that sounds complicated, so a summary:
pppd reads /etc/ppp/options.
pppd executes /etc/ppp/net-connect.
chat reads data from /etc/ppp/net-chat.
pppd obtains IP address details from server.
pppd creates ppp0 device and configures it.
pppd creates default route.
pppd runs in background.
To test the connection, do each of the following steps in turn.
The ifconfig program is used to set or display network interface configurations. Here you are interested in displaying only.
The output should look like Listing 1.
The inet addr field is the IP address you have been allocated. The P-t-P field is the address of the PPP machine at the other end of the link. This means your PPP network connection has been successfully established.
If you don't see a ppp0 device, check your system log file, i.e., /var/adm/messages, to ensure that your chat script worked successfully. Correct any possible errors. If you see any nasty looking error messages, double check that you are using the correct version of PPP for your kernel.
Step 3: ping the PPP Remote Host. The ping command sends specially formatted datagrams to a host that that host will send replies to. This allows us to check that we have a working route to that host. Listing 2 shows our case. Those “64 bytes from ...” lines in the listing mean we are talking successfully to the machine at the other end of the link. This is good, since it means the link is working.
If you don't see any of the “64 bytes from ...” lines, this means you are not properly talking to the remote machine. Double check your chat script and the system log file.
Step 4: ping your nameserver. This is an important test to be sure the default route pppd put in place is working. To do this, ping the nameserver address configured into the /etc/resolv.conf file. In our case:
# ping 184.108.40.206
Output will be similar to what you observed when you pinged the PPP server.
If this test fails, it could mean your default route hasn't been added properly. To double check, run the route command as shown in Listing 3. The route command displays the contents of the IP routing table. The -n option tells it not to try and convert IP addresses into host names. The line starting with 0.0.0.0 is the default route. If you don't see a line like this, double check that you have included the defaultroute option in the /etc/ppp/options file. If you have a line like this but it doesn't point to ppp0, check that your system isn't already creating a default route to another device. If it is, find which rc file is doing it and comment out this entry.
Step 5: ping a remote host. This is the real and simple test. Try either:
# ping sunsite.unc.edu
# ftp ftp.funet.fiIf this works, you are connected properly to the Internet. Enjoy.
If the command just sits there and, after a minute or so, gives you an error message about being unable to resolve the host name, check that you have modified your /etc/resolv.conf file correctly, and that the IP address you have configured there is the correct IP address for your ISP's nameserver.
Practical Task Scheduling Deployment
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.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- Stunnel Security for Oracle
- The Firebird Project's Firebird Relational Database
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- 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
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