First Released August 1994
Last updated December 1997
This is an ancient post with no relevance to modern systems.
This is a brief guide to configuring a system running SCO Unix & TCP/IP, Open Desktop, or Open Server 5 to work with Xmission. You will need SCO ODT 3.0 or above, or SCO Unix 3.2v4.2 with the most recent version of TCP/IP. The version of TCP/IP included in ODT 2.0 will not work with Xmission's PPP and most other ISP's. Use it at your own risk.
To avoid some problems associated with PPP, you should install the SLS net382e on your system for ODT 3.0 or SCO UNIX 3.2v4.2 with TCP/IP. This is essential to making the link work properly. You can safely configure the system and then download the SLS from ftp.sco.com if necessary.
Information contained in this guide includes:
It is assumed that you are familiar with the operation and administration of SCO Unix and ODT and that you are using the standard SCO packages, rather than additional networking products such as Morningstar PPP.
When you configure your connection to Xmission or ISP with SCO you need to use a PPP connection. Please check the options you are using.
1. PPP Software version to work with Xmission and most ISP's included in ODT 3 or Unix 3.2v4.2 and a versions of TCP/IP or Openserver 5.0.X No Yes 2. Dial on demand No Yes 3. Dial in connections No Yes
Most of this document will deal with the issues concerning PPP. The scripts referred to should be easily adaptable to deal with your specfic case. They have worked with pppattach and a pseudo dynamic PPP. PPP is recommended where possible. Your chosen interface should be configured using netconfig in the usual way, with the remote address being specified as the address of the Xmission PoP or your ISP PoP that you will be dialling in to. For example: If you will be i calling from a SLC PoP, which uses eight different systems to answer the phone, specify the address of any one of the machines, such as slc1-tc (166.70.1.20).
If you are using pppattach, it is possible to initiate a connection manually. First make sure you can cu internet. If you can do that then start the pppattach process on line as root.
Your modem should be configured according to the instructions in Xmission's Modem.txt file or Modem.txt on ftp.zenez.com/pub/zenez/. Broadly speaking, Your MODEM should be set with a constant speed between the SCO system and the MODEM, with all speed buffering and negotation of compression and error handling taking place in the modem. Use hardware handshaking and make sure that the modem is connected to the modem control port (ie. tty2A not tty2a). Note if you are using above 19200 you will need a 16550 Uart or equiv. on your mother board or your serial interface.
On the the ZENEZ server in the our office, 66MHz 486DX2, we manage a reliable data rate of 19200 bps on a standard serial card. Our main system at ZENEZ, we have reliable rates of 38400 are achieved with a 16550-based serial port. Higher speeds are not possible using the standard SCO serial drivers, and if you are using a 16550 chip you would be advised to alter the interrupt trigger level, TTHOG and NCLIST. Details of how to do this are in the manuals for ODT 3.0 and in a technical support script for SCO that can be downloaded from the web (www.sco.com), telnet (ftp.sco.com) or SCOFORUM on CompuServe. Details on how to configure one of ZENEZ's 16550 cards as a third serial port under ODT can be obtained by mailing me as gerberb@zenez.com.
If you wish to run the modem at speeds higher than 38400 (which is currently the speed at which ZENEZ run their modems) you will need to install alternative serial port drivers such as FAS, or use a multiport card from suppliers such as Specialix and Digi and make changes as in the technical support scripts at SCO.
This file tells ppp which UUCP host to dial when you try to establish a connection via the network. You will need a line like the following, which I use in place of the one added by netconfig.
ODT 3.0 or Unix 3.2v4.2 and TCP/IP the first field relates to the remote address of the PPP link and can be substituted for the numeric address. The example below is suitable for a dedicated line connection. For a standard connection you should have an entry like slc1-tc in the first field (or your local PoP). Whichever name appears here must correspond to an entry in your nameserver or in /etc/hosts if no nameserver is being used.
The third field is the name of the UUCP system, and must be exactly the same as the entry in your Systems file.
Field four defines the time, in minutes, that the link must be idle before the phone hangs up.
ODT 3.0/Unix 3.2v4.2 and TCP/IP /etc/ppphosts slc1-tc - slc1-tc idle=5 tmout=8 flow=rtscts name=user_name ipaddr proxy *nppp - - flow=rtsctss auth=pap name=nppp
OSR5 /etc/ppphosts slc1-tc:route-ppp idle=5 flow=rtscts name=user_name proxy *nppp local=ppp-xenau remote=*zen idle=10 flow=rtscts auth=pap name=nppp
This file contains your password and login details for Xmission. The entry below has proved to be sufficient to handle delays when logging in at busy times.
ODT 3.0/Unix 3.2v4.2 and TCP/IP without PAP slc1-tc Any ACU 19200 9900900 name: user-name@ppp ssword: user-passwd *** OLD *** annex1 Any ACU 19200 5390900 umber: 3 name: user-name ssword: user-passwd
If you have a better serial conection, change the speed entry from 19200 to 38400. You should also change the phone number to reflect the PoP that you will be calling, and add your user name and password. For PAP use the following:
ODT 3.0/Unix 3.2v4.2 and TCP/IP with PAP slc1-tc Any ACU 38400 9900900 *** OLD *** annex1 Any ACU 38400 5390900
And the following in /etc/pppauth
/etc/pppauth *user-name user-passwd nppp nppp-passwd
The same script may be used for reserved line dial ups.
You may use one of the standard dialers, or alternatively put an entry like this in the Devices file and an entry is Dialers as described below.
ACU tty2A - 1200-38400 hayes
or
ACU tty2A - 1200-38400 atdialUSR \D and link atdialer to
atdialUSR
The following lines are sufficient to dialling Xmission with a modem that has all the necessary settings already configured. I use this in preference to letting software written by other people fiddle with my modems. You may feel differently.
pre> # Hayes compatible # hayes =,-, "" AT\r\c OK\r ATDT\T\r\c CONNECT
Before your connection will work properly, you need to configure the routing to Xmission or your ISP. The net result of setting up your routing should be a response similar to the one below when you issue the command netstat -r.
OSR5 Routing tables Destination Gateway Flags Refs Use Interface default slc1-tc.xmission.c UGS 5 29212 ppp0 localhost localhost UH 4 5146 lo0 slc1-tc.xmission route-ppp UH 3 4670 ppp0 class_c ether-net UC 1 0 net0 host_name localhost UGHS 4 1048 lo0 ppp-route localhost UGHS 0 0 lo0 BASE-ADDRESS.MCA xenau UCS 0 0 net0
You can point your default route directly at xmission slc1-tc, rather than at your end of the Xmission or ISP link, but this will tend to result in some unnecessary calls to Xmission. This is a must for using pppattach
The necessary routes can be added (assuming that we were connecting to slc1-tc) with the commands
route add default ppp-route 0 route add ppp-route slc1-tc 1
If you are running a nameserver, you must ensure that the addresses for both ends of your link are capable of being resolved by your nameserver, otherwise PPP won't work properly. This is also the case if you are relying on /etc/resolv.conf to handle your resolution for you.
This is the simplest way to make your system work with Xmission for resolving external addresses, but not recommended. Configuring a nameserver is much better (and more fun!) and won't result in unwanted calls. If you do decide to use resolv.conf on its own, use entries like these
ODT 3.0/Unix 3.2v4.2 and TCP/IP domain xmission.com nameserver 198.60.22.2
OSR5 domain xmission.com hostresorder local bind nameserver 198.60.22.2
Note: You should change xmission.com to your Domain Name above.
When you're initially testing PPP, don't bother with this, or with a nameserver. Just make sure that you have entries in /etc/hosts for the PoP that you're calling, for your own machine and for important systems like mail.xmission.com or any that your ISP requires. That will be sufficient for testing the link (usually with a command like finger username@slc1-tc.xmission.com)
If you're using PPP you shouldn't have problems sharing a line using the standard SCO getty. Make sure you use lower case for direct and upper case for MODEM control. Here is the sample Devices and Systems files I use in /usr/lib/uucp. These are just the tail end to the existing files. Replace the 9900900 with the number to Xmission or your ISP's number.
Devices --------------------------------------------------------------------- TCP TCP,e - Any TCP 540 Direct tty2a - 2400-38400 direct ACU tty2A - 1200-38400 atdialUSR \D
Systems --------------------------------------------------------------------- xmission Any TCP,e Any - ogin:-BREAK-ogin:-BREAK-ogin: Username ssword: password slc1-tc Any ACU 38400 9900900 slc2-tc Any ACU 38400 9900900 slc3-tc Any ACU 38400 9900900 slc4-tc Any ACU 38400 9900900 slc5-tc Any ACU 38400 9900900 slc6-tc Any ACU 38400 9900900 slc7-tc Any ACU 38400 9900900 slc8-tc Any ACU 38400 9900900 internet Any ACU 38400 9900900
Note: If you need to change the scripting make sure that you have both pairs (what to expect) (What to send) (expect) (send) ...
Although it looks pretty scary, the effort involved in setting up a nameserver to work with Xmission or your ISP is well worth it. You should be able to copy the examples below or down load samp_files.tar.Z from /archive/sco on Xmission or /pub/zenez/ on ftp.zenez.com. Note: that for my test system (test.xenex.zenez.com) the system name is actually test, and mmdf is configured to hide it behind xenex.zenez.com. This step is not strictly necessary but may mean that you don't have to change you system's name when you hook up to Xmission or your ISP.
The nameserver works in a mysterious way; assume that you have a domain such as xenau.zenez.com and a machine called test within that domain.
If a query 'test' is received, the server appends xenex.zenez.com to the end and, since it knows it is authoritative for xenex.zenez.com is able to satisfy the request.
If a query for 'test.xenex.zenez.com.' (note the last . ) is received, the server also knows that it can resolve the query.
Without the last . on such a query ('test.xenex.zenez.com') the server appends xenex.zenez.com and discovers that there is no host called test.xenex.zenez.com.xenex.zenez.com, so it then strips off a component of the domain and tries to look up test.xenex.zenez.com.zenez.com. Since this address isn't one about which the server knows, it will try to query Xmission's or your ISP's nameserver, at which point a call will be made to i your local PoP. If you don't have your nameserver set up to call Xmission or your ISP, then you'll rather defeat the point of having it, since you won't be able to query off-site hosts.
A simple way round this is to remember that you should always use just a local host name, or put a trailing . on the end of a full host name, but life isn't that simple. If you use any programs that perform a reverse lookup on incoming connections, like tcp_wrappers or a POP mail server, or nntpd, they too will call Xmission or your ISP when a connection is received. The solution is to put a CNAME (alias) entry in your nameserver files so that when the second query is made, it's resolved by your own nameserver before being passed to Xmission or your ISP.
For example, by creating a CNAME entry stating equivalence between test.xenex.zenez.com and test.xenex.zenez.com.zenez.com, you can avoid the second lookup.
Example name server files are shown below for my sample system. Similar (virtually identical) ones are used for zenez.com. Note that I have an additional interface on my system, connected to an ethernet, and the addresss of that interface (198.60.105.1) is used as the nameserver address. You could equally well point the nameserver address at the ppp interface, 198.60.105.2
A final point, for people who are running ODT is that the files /etc/X0.hosts, /etc/X1.hosts and so forth contain a line that begins #Authorised hosts. This line is not interpreted as a comment, and should be removed (leaving the files empty on most systems) otherwise the system will try to look up a host called #Authorised each time the X server starts.
The following name server files are held in /usr/local/domain on my system, with named.boot symbolically linked to /etc/named.boot to ensure automatic startup when the system is booted. You may want to add them to /etc/named.d on OpenServer 5.0.X. Please compare before you over write any of the files in that directory or make a backup.
The named_samp.tar.Z can be uncompressed and untar'ed in the directory /usr/local/domain. Here is the list of files that should be created.
README File containing the contents. db.198.60.105 PTR file for nameserver hosts Sample /etc/hosts for reference. named.boot Sample /etc/named.boot for reference. named.local Standard named local DNS file. resolv.conf Sample reslov.conf file. root.cache Standard named cache file. route Sample file for S99route in /etc/rc2.d. zenez.198.60.105 Sample Xmission IN-ADDR.ARPA file for a domain. zenez.com Sample Xmission db file for a domain.
hosts --------------------------------------------------------------------- # @(#)hosts 1.2 Lachman System V STREAMS TCP source # SCCS IDENTIFICATION # # All machines need a local host # 127.0.0.1 localhost # # Xmission hosts that need to be in /etc/hosts # 198.60.22.2 xmission.xmission.com gate.xmission.com xmission 198.60.22.22 mail.xmission.com mailx.xmission.com 198.60.22.4 news.xmission.com 166.70.22.6 annex1.xmission.com annex1 166.70.22.8 annex2.xmission.com annex2 166.70.22.15 annex3.xmission.com annex3 166.70.22.7 dedannex.xmission.com dedannex 166.70.1.20 slc1-tc.xmission.com slc1-tc 166.70.1.40 slc2-tc.xmission.com slc2-tc 166.70.1.21 slc3-tc.xmission.com slc3-tc 166.70.1.41 slc4-tc.xmission.com slc4-tc 166.70.1.22 slc5-tc.xmission.com slc5-tc 166.70.1.42 slc6-tc.xmission.com slc6-tc 166.70.1.23 slc7-tc.xmission.com slc7-tc 166.70.1.43 slc8-tc.xmission.com slc8-tc # # Your Domain hosts that need to be in /etc/hosts # 198.60.105.1 xenau zenez.com xenau.zenez.com 198.60.105.2 route-ppp route-ppp.zenez.com 198.60.105.3 www2 www2.zenez.com 198.60.105.4 www3 www3.zenez.com 198.60.105.5 www4 www4.zenez.com 198.60.105.6 www5 www5.zenez.com 198.60.105.10 ppp-xenau ppp-xenau.zenez.com 198.60.105.11 ppp1-xenau ppp1-xenau.zenez.com 198.60.105.12 ppp2-xenau ppp2-xenau.zenez.com 198.60.105.13 ppp3-xenau ppp3-xenau.zenez.com 198.60.105.14 ppp4-xenau ppp4-xenau.zenez.com 198.60.105.15 ppp5-xenau ppp5-xenau.zenez.com 198.60.105.16 ppp6-xenau ppp6-xenau.zenez.com 198.60.105.17 ppp7-xenau ppp7-xenau.zenez.com 198.60.105.18 ppp8-xenau ppp8-xenau.zenez.com 198.60.105.19 ppp9-xenau ppp9-xenau.zenez.com 198.60.105.254 dumb dumb.zenez.com
I link /usr/local/domain/named.boot to /etc/named.boot.
named.boot --------------------------------------------------------------------- ; ; Name Server boot file for "Domain" zenez.com ; Type Domain Source file ; Purpose This file is for Hosts that serve as primary server's ; ; This file was created by Boyd Gerber 12/04/1991 ; ; domain zenez.com ; ; Copyright (C) 1991-1995 ZENEZ ; ; Last modified by Boyd Gerber 01/01/1995 ; ; directory /usr/local/domain cache . named.ca primary zenez.com zenez.com primary 105.60.198.in-addr.arpa zenez.198.60.105 primary 0.0.127.in-addr.arpa named.local forwarders 198.60.22.2 zenez.com ------------------------------------------------------------------------ zenez.com. IN SOA zenez.com. pashdown.xmission.com. ( 1995102201; Serial 10800 ; Refresh 1800 ; Retry 3600000 ; Expire 86400 ) ; Minimum IN NS ns1.xmission.com. IN NS ns1.sierra.net. ; Last Modified By: ; Boyd Lynn Gerber ; gerberb@zenez.com ; gerberb@xmission.com ; ; accountname: gerberb ; ; file: zenez.com ; ; hosts for zenez.com ; localhost IN A 127.0.0.1 zenez.com. IN A 198.60.105.1 route-ppp IN A 198.60.105.2 ppp-xenau IN A 198.60.105.10 ppp1-xenau IN A 198.60.105.11 ppp2-xenau IN A 198.60.105.12 ppp3-xenau IN A 198.60.105.13 test1 IN A 198.60.105.251 dumb IN A 198.60.105.254 xenau IN CNAME zenez.com. news IN CNAME zenez.com. zenez IN CNAME zenez.com. mail IN CNAME zenez.com. gate IN CNAME zenez.com. www IN CNAME zenez.com. ftp IN CNAME zenez.com. ns IN CNAME zenez.com. ether-xenau IN CNAME zenez.com. zenez.com. IN MX 5 zenez.com. zenez.com. IN MX 10 xmission.com. test.zenez.com. IN MX 5 zenez.com. test.zenez.com. IN MX 10 xmission.com. ;Off site hosts gate.xmission.com. IN A 198.60.22.2 xmission.xmission.com. IN A 198.60.22.2 mail.xmission.com. IN A 198.60.22.22 annex1.xmission.com. IN A 166.70.22.6 annex2.xmission.com. IN A 166.70.22.8 annex3.xmission.com. IN A 166.70.22.15 dedannex.xmission.com. IN A 166.70.22.7 slc1-tc.xmission.com. IN A 166.70.1.20 slc2-tc.xmission.com. IN A 166.70.1.40 slc3-tc.xmission.com. IN A 166.70.1.21 slc4-tc.xmission.com. IN A 166.70.1.41 slc5-tc.xmission.com. IN A 166.70.1.22 slc6-tc.xmission.com. IN A 166.70.1.42 slc7-tc.xmission.com. IN A 166.70.1.23 slc8-tc.xmission.com. IN A 166.70.1.43 provo1-tc.xmission.com. IN A 166.70.1.44 ; ; fixes for PPP ; test.xenex.zenez.com.zenez.com. IN CNAME test.xenex.zenez.com. ether-xenau.zenez.com.zenez.com. IN CNAME ether-xenau.zenez.com. zenez.198.60.105 ---------------------------------------------------------------------------- 105.60.198.in-addr.arpa. IN SOA zenez.com. pashdown.xmission.com. ( 1995102201; Serial 10800 ; Refresh after 3 hours 3600 ; Retry after 1 hour 604800 ; Expire after 1 week 86400 ) ; Minimum TTL of 1 day IN NS ns1.xmission.com. IN NS ns1.sierra.net. ; ; Last Modified By: ; Boyd Lynn Gerber ; gerberb@zenez.com ; gerberb@xmission.com ; ; accountname: gerberb ; ; file: zenez.198.60.105 ; ; hosts for zenez.com ; 1 IN PTR zenez.com. 2 IN PTR route-ppp.zenez.com. 10 IN PTR ppp-xenau.zenez.com. 11 IN PTR ppp1-xenau.zenez.com. 12 IN PTR ppp2-xenau.zenez.com. 13 IN PTR ppp3-xenau.zenez.com. 251 IN PTR test.zenez.com. 254 IN PTR dumb.zenez.com. named.local ----------------------------------------------------------------------------- ; @(#)named.local 4.2 LAI System V.3 STREAMS TCP/IP source ; ; Don't forget to increment the serial number ; @ IN SOA zenez.com. gerber.xenau.zenez.com. ( 100 ; Serial 10800 ; Refresh 1800 ; Retry 3600000 ; Expire 86400 ) ; Minimum IN NS ns.zenez.com 1 IN PTR localhost. root.cache ---------------------------------------------------------------------------- ; @(#)root.cache 5.1 LAI System V.3 STREAMS TCP/IP source ; ; @(#) root.cache 1.1 96/03/27 ; ; Prep the cache (hotwire the addresses). Order does not matter ; Initial cache data for root domain servers. ; . 518400 IN NS ns.zenez.com 518400 IN NS A.ROOT-SERVERS.NET. 518400 IN NS B.ROOT-SERVERS.NET. 518400 IN NS C.ROOT-SERVERS.NET. 518400 IN NS D.ROOT-SERVERS.NET. 518400 IN NS E.ROOT-SERVERS.NET. 518400 IN NS F.ROOT-SERVERS.NET. 518400 IN NS G.ROOT-SERVERS.NET. 518400 IN NS H.ROOT-SERVERS.NET. 518400 IN NS I.ROOT-SERVERS.NET. zenez.com. 518400 IN NS 198.60.105.1 xmission.com. 518400 IN NS 198.60.22.2 ; ; Root servers by address ; ns.zenez.com. 518400 IN A 198.60.105.1 xmission.com. 518400 IN A 198.60.22.2 A.ROOT-SERVERS.NET. 518400 IN A 198.41.0.4 B.ROOT-SERVERS.NET. 518400 IN A 128.9.0.107 C.ROOT-SERVERS.NET. 518400 IN A 192.33.4.12 D.ROOT-SERVERS.NET. 518400 IN A 128.8.10.90 E.ROOT-SERVERS.NET. 518400 IN A 192.203.230.10 F.ROOT-SERVERS.NET. 518400 IN A 192.5.5.241 G.ROOT-SERVERS.NET. 518400 IN A 192.112.36.4 H.ROOT-SERVERS.NET. 518400 IN A 128.63.2.53 I.ROOT-SERVERS.NET. 518400 IN A 192.36.148.17 ODT 3.0/Unix 3.2v4.2 and TCP/IP /etc/resolv.conf ---------------------------------------------------------------------------- domain zenez.com nameserver 198.60.105.1 nameserver 206.26.97.2 nameserver 198.60.22.2 OSR5 /etc/resolv.conf ---------------------------------------------------------------------------- domain zenez.com hostresorder local bind nameserver 198.60.105.1 nameserver 206.26.97.2 nameserver 198.60.22.2
As ever, make sure that it you decide to have an address for an additional interface on your system, it is not one that will be allocated and/or used elsewhere. There are other ways to configure your nameserver which may work better. This one works for me, but is somewhat reliant on hiding your machine names behind your domain (or another domain if you have mailforwarding).
If you intend to configure a name server (and I recommend it) then you should do that before configuring the mail system. The standard SCO mail system is MMDF and I have experienced few problems with it. Configuration is done as user mmdf from the /usr/mmdf directory, by running the command mkdev mmdf.
If you want mail.xmission.com or you ISP's mail machine to handle all your mail, you may configure mmdf before setting up the name server, or tell the configuration program that you don't want to use the nameserver.
In any case, you should name mail.xmission.com or your ISP's mail host as the host to which 'badhosts' mail will be sent. If you have set up your system with a nameserver as per the configuration above, ensure that you hide local machine names behind your domain.
To prevent excessive redials, alter the mmdf startup script and crontabs so that a background deliver daemon is not run. You may also want to change the badhosts entry in /usr/mmdf/mmdftailor from mod=imm to mod=reg. This means that mmdf will not try to deliver mail to the badhosts channel immediately (thus initiating a call to Xmission or ISP). Instead, mail will be queued and can be delivered manually or via cron with the command /usr/mmdf/bin/deliver -cbadhosts .
If you have changed from a standard Xmission account to one with mail forwarding, you may wish to configure your mail system to accept multiple domains as local. For example, the system at work will accept and deliver mail for both gerberb@zenez.com and gerberb@xenau.zenez.com. For information on how to configure this, please contact me using the address gerberb@zenez.com.
Connecting a whole network to Xmission or ISP is pretty much the same as connecting a single machine, but with rather more entries in your nameserver. The chief difference is that when you use the netconfig command to set up your network interface, you must tell the script that the machine will be used as a gateway.
If the gateway machine is providing any services to systems, regardless of whether or not those systems will themselves be connecting to the outside world, that require reverse lookups to be made - eg POP mail retrieval - you will need to ensure that there is a CNAME entry for each system, as described in the section above.
If you have a dedicated line connection, you will be able to use PPP and dial on demand without any problems, as this service from Xmission always presents you with a connection to the same host.
The version of PPP currently shipping with SCO products is not able to negotiate the remote IP address correctly. Dial up links in general are not supported with SCO's SLIP, which means that you will only be able to have a reliable dial on demand connection when using PPP to call either a PoP at which there is only one machine (and so a fixed remote IP address) or when using a Network Dial Up Dedicated Line connection.
The script Start_PPP will bring up a manual bringup link and add routing. The command must be run as root, and you will need an additional entry in /etc/ppphosts as described in the section 'Using a line for both dial in and dial out,' beginning with the token *nppp if you are running a getty on the line. The script check_PPP will bring up a manual bringup link and monitor the link and add routing.
As always, there are more elegant and better ways to handle this, but it works. If you can find a way to put the same functionality into a dialer, you'll be able to have full dial on demand even when calling any Xmission PoP.
xc is available on the SCO Skunkware CD-ROM, via ftp to ftp.sco.com or from ftp.celestial.com
tcp_wrappers can be obtained from ftp.celestial.com
Some software may also be obtained from SCOFORUM on CompuServe.
I may be able to offer compiled versions of some software on a best effort basis.
Scripts are all available at ftp.zenez.com Check in /pub/zenez for them and other useful information.
All this information is provided pm a best-effort basis. Back up your system before doing anything to it, and don't blame me if it all goes horribly wrong.
Got something to add? Send me email.
More Articles by Boyd Lynn Gerber © 2012-07-14 Boyd Lynn Gerber
While we all ooh and ahh over the reports and graphs, Google is quietly building an incredible pile of extremely valuable information. (Tony Lawrence)
Printer Friendly Version
PPP and DNS Configuration Copyright © November 2001 Boyd Lynn Gerber
Have you tried Searching this site?
This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.
Contact us
Printer Friendly Version