Building an ISP Using Linux and an Intranet
Once your connection to the Internet is stable, it is time to connect your network. Your Linux machine and your other machines should all have network cards installed, and your Linux machine should have the kernel compiled with the appropriate drivers.
Suppose you want to set up Doofus (a Windows 95 client) and hook into your network to give it access to the Internet. Pick an IP address for Doofus of 22.214.171.124 (it can be any number available within your Class C block). To set up the Windows 95 machine to access your Linux server, you must go into the Control Panel and pick Network. Make sure TCP/IP is bound to your network card. The Properties button lets you set up the following items on each of your machines:
IP Address: If you have a Class C address, you can assign an IP address 126.96.36.199 and a subnet mask of 255.255.255.0.
DNS Configuration: Pick Enable DNS and give your machine the name Doofus for the host and NetBrain.com for the domain. This setup provides the Windows machine with the name Doofus.NetBrain.com—or read another way, Doofus is within NetBrain.com. The DNS Server Search Order should have your DNS entries added to be the same as the Linux server's /etc/resolv.conf nameserver entries.
WINS Configuration: Pick Disable WINS Resolution
Bindings: Add a gateway to your Linux machine. The gateway helps your machine find its way out of the network and onto the Internet. We added 188.8.131.52 to the list of installed gateways.
After you've rebooted your Win95 machine, you should be able to ping it from your Linux host using ping 184.108.40.206. If it fails, possible problems could be the cable, Linux drivers, Win95 drivers or your Win95 configuration. Now from the other side... When you're ready to test your Windows 95 client, open an MS-DOS window and ping your server. The command ping 220.127.116.11 should get a response from your server. You should be able to TELNET to your machine (telnet mickeymouse.com) and should also be able to bring up a browser and go to any web site that interests you. It's that easy.
Most personal computers have only two serial ports, and one of those is usually used by the mouse. The best way to provide dial-up access is to purchase a multiport serial card. We use the Cyclades Cyclom 16Yep card, which provides 16 serial ports for modem use. More important, the drivers are built into the Linux kernel.
Before you purchase a specific card, make sure the drivers for the card exist and your machine has the drivers compiled into the kernel. You might have to create the ports your serial card uses with MAKEDEV. Our Cyclades card uses ttyC0-ttyC15 for the serial ports instead of the standard ttyS0 and ttyS1 for the standard serial ports. Fortunately, the Cyclades card came with a makecyc install script that did the work for me.
The program setserial needs to be called to initialize the serial port(s). The /etc/rc.d/rc.serial file may need to be edited to properly set up your server's serial ports. To use com2 for the dial-out modem, put the following line in rc.serial:
#standard serial port - com2: setserial /dev/cua1 spd_vhi auto_irq autoconfig
For the Cyclades card, I configured the ports 3-10 /dev/cub2 - /dev/cub10 (some unused—for expansion) as follows:
#configure Cyclades serial ports setserial -b /dev/cub2 spd_vhi autoirq skip_test setserial -b /dev/cub3 spd_vhi autoirq skip_test setserial -b /dev/cub4 spd_vhi autoirq skip_test setserial -b /dev/cub5 spd_vhi autoirq skip_test setserial -b /dev/cub6 spd_vhi autoirq skip_test setserial -b /dev/cub7 spd_vhi autoirq skip_test setserial -b /dev/cub8 spd_vhi autoirq skip_test setserial -b /dev/cub9 spd_vhi autoirq skip_testMake sure the rc.serial file is called from one of the startup rc files, usually rc.s. This will configure your serial ports automatically during boot.
Next, you need to configure the host to listen to the serial port for incoming connections and to to answer these connections. The /etc/gettydefs file is used to set up the gettys which make connections to the machine. When a standard version of Linux is installed, you find these lines in the /etc/gettydefs file:
c1:1235:respawn:/sbin/agetty 38400 tty1 linux c2:1235:respawn:/sbin/agetty 38400 tty2 linux c3:1235:respawn:/sbin/agetty 38400 tty3 linux c4:1235:respawn:/sbin/agetty 38400 tty4 linux c5:1235:respawn:/sbin/agetty 38400 tty5 linux c6:12345:respawn:/sbin/agetty 38400 tty6 linux
This provides your console (keyboard) with six virtual logins. The fourth item in the line /sbin/agetty is the program polling the console for a login. The following parameters describe the login speed, terminal number and terminal emulation. You add the following lines for dial-up lines after the parameters list.
# Dial-up lines using /sbin/getty # (actually getty_ps) s1:345:respawn:/sbin/getty ttyC2 115200 vt100 s2:345:respawn:/sbin/getty ttyC3 115200 vt100 s3:345:respawn:/sbin/getty ttyC4 115200 vt100We use a different getty (getty_ps) for our dial-up lines because of trouble using agetty on the serial port. We also also heard that getty_ps is more reliable. You can also use mgetty for the dial-up lines, but getty_ps works great for us. The parameters for getty_ps are slightly different, however: parameters following the getty name are the tty, the /etc/gettydef label and the terminal emulation default. The 115200 in the preceding lines refers to the label in /etc/gettydefs file shown here:
#/etc/gettydefs # Modem locked at 115200: Serial port is at # 115200, modem is much less, but should be # able to compress. # # Last line of this file is described in next # comment line as fields separated by # signs. # label # initial-flags # final-flags # login prompt # next label 115200# B115200 CS8 CRTSCTS # B115200 SANE -ISTRIP CRTSCTS #@S login: #115200Now you have to provide the getty_ps with the startup values. In the directory /etc/defaults, place the configuration files for each dial-up line. For the dial-up line /dev/ttyC2, we have a corresponding file called /etc/default/getty.ttyC2 shown in Listing 3.
If everything works as planned, the host should be able accept shell logins. You should be able to dial into your machine and run commands in the shell.
To monitor the dial-up connection, you can set the DEBUG=777 in the /etc/default/getty.tty?? file to create a log file. This will help you identify problems should the modem not answer or not configure properly. The output is dumped to the syslog file usually in /var/adm/syslog.
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
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Tech Tip: Really Simple HTTP Server with Python
- Non-Linux FOSS: Caffeine!
- 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