Slackware Linux Essentials - Chapter 5 Network Configuration
Warning: file_get_contents(http://ecs.amazonaws.com/onca/xml?Service=AWSECommerceService&AWSAccessKeyId=1TJ8QTQ6ZFCVAJ3X1T02&AssociateTag=ii0c3-20&Operation=ItemSearch&SearchIndex=Books&ResponseGroup=Small,Images&Keywords=account) [function.file-get-contents]: failed to open stream: HTTP request failed! HTTP/1.1 400 Bad Request in /home/manusia2/public_html/wp-content/plugins/amazonfeed/php/amazonfeed.class.php on line 271
5.1 Introduction: netconfig is your friend.
When you initially installed Slackware, the setup program invoked the netconfig program. netconfig attempted to perform the following functions for you:
-
It asked you for the name of your computer, and the domain name for your computer.
-
It gave a brief explanation of the various types of addressing schemes, told when they should be used, and asked you which IP addressing scheme you wished to use to configure your network card:
-
Static-IP
-
DHCP
-
Loopback
-
-
It then offered to probe for a network card to configure.
netconfig will generally take care of about 80% of the work of configuring your LAN network connection if you will let it. Note that I would strongly suggest that you review your config file for a couple of reasons:
-
You should never trust a setup program to properly configure your computer. If you use a setup program, you should review the configuration yourself.
-
If you are still learning Slackware and Linux system management, viewing a working configuration can be helpful. You’ll at least know what the configuration should look like. This will allow you to correct problems due to misconfiguration of the system at a later date.
5.2 Network Hardware Configuration
Having decided that you wish to bring your Slackware machine on to some form of network, the first thing you’ll need is a Linux-compatible network card. You will need to take a little care to ensure that the card is truly Linux-compatible (please refer to the Linux Documentation Project and/or the kernel documentation for information on the current status of your proposed network card). As a general rule, you will most likely be pleasantly surprised by the number of networking cards that are supported under the more modern kernels. Having said that, I’d still suggest referring to any of the various Linux hardware compatibility lists (such as The GNU/Linux Beginners Group Hardware Compatibility Links and The Linux Documentation Project Hardware HOWTO) that are available on the Internet before purchasing your card. A little extra time spent in research can save days or even weeks trying to troubleshoot a card that isn’t compatible with Linux at all.
When you visit the Linux Hardware Compatibility lists available on the Internet, or when you refer to the kernel documentation installed on your machine, it would be wise to note which kernel module you’ll need to use to support your network card.
5.2.1 Loading Network Modules
Kernel modules that are to be loaded on boot-up are loaded from the rc.modules file in /etc/rc.d or by the kernel’s auto module loading started by /etc/rc.d/rc.hotplug. The default rc.modules file includes a Network device support section. If you open rc.modules and look for that section, you’ll notice that it first checks for an executable rc.netdevice file in /etc/rc.d/. This script is created if setup successfully autoprobes your network device during installation.
Below that “if” block is a list of network devices and modprobe lines, each commented out. Find your device and uncomment the corresponding modprobe line, then save the file. Running rc.modules as root should now load your network device driver (as well as any other modules that are listed and uncommented). Note that some modules (such as the ne2000 driver) require parameters; make sure you select the correct line.
5.2.2 LAN (10/100/1000Base-T and Base-2) cards
This heading encompasses all of the internal PCI and ISA networking cards. Drivers for these cards are provided via loadable kernel modules as covered in the previous paragraph. /sbin/netconfig should have probed for your card and successfully set up your rc.netdevice file. If this did not occur, the most likely problem would be that the module that you’re attempting to load for a given card is incorrect (it is not unheard of for different generations of the same brand of card from the same manufacturer to require different modules). If you are certain that the module that you’re attempting to load is the correct one, your next best bet would be to refer to the documentation for the module in an attempt to discover whether or not specific parameters are required during when the module is initialized.
5.2.3 Modems
Like LAN cards, modems can come with various bus support options. Until recently, most modems were 8 or 16 bit ISA cards. With the efforts of Intel and motherboard manufacturers everywhere to finally kill off the ISA bus completely, it is common now to find that most modems are either external modems that connect to a serial or USB port or are internal PCI modems. If you wish for your modem to work with Linux, it is VITALLY important to research your prospective modem purchase, particularly if you are considering purchasing a PCI modem. Many, if not most, PCI modems available on store shelves these days are WinModems. WinModems lack some basic hardware on the modem card itself: the functions performed by this hardware are typically offloaded onto the CPU by the modem driver and the Windows operating system. This means that they do not have the standard serial interface that PPPD will be expecting to see when you try to dial out to your Internet Service Provider.
If you want to be absolutely sure that the modem you’re purchasing will work with Linux, purchase an external hardware modem that connects to the serial port on your PC. These are guaranteed to work better and be less trouble to install and maintain, though they require external power and tend to cost more.
There are several web sites that provide drivers and assistance for configuring WinModem based devices. Some users have reported success configuring and installing drivers for the various winmodems, including Lucent, Conexant, and Rockwell chipsets. As the required software for these devices is not an included part of Slackware, and varies from driver to driver, we will not go into detail on them.
5.2.4 PCMCIA
As part of your Slackware install, you are given the opportunity to install the pcmcia package (in the “A” series of packages). This package contains the applications and setup files required to work with PCMCIA cards under Slackware. It is important to note that the pcmcia package only installs the generic software required to work with PCMCIA cards under Slackware. It does NOT install any drivers or modules. The available modules and drivers will be in the /lib/modules/`uname -r`/pcmcia directory. You may need to do some experimentation to find a module that will work with your network card.
You will need to edit /etc/pcmcia/network.opts (for an Ethernet card) or /etc/pcmcia/wireless.opts (if you have a wireless networking card). Like most Slackware configuration files, these two files are very well commented and it should be easy to determine which modifications need to be made.
5.3 TCP/IP Configuration
At this point, your network card should be physically installed in your computer, and the relevant kernel modules should be loaded. You will not yet be able to communicate over your network card, but information about the network device can be obtained with ifconfig -a.
# ifconfig -a eth0 Link encap:Ethernet HWaddr 00:A0:CC:3C:60:A4 UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1 RX packets:110081 errors:1 dropped:0 overruns:0 frame:0 TX packets:84931 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:114824506 (109.5 Mb) TX bytes:9337924 (8.9 Mb) Interrupt:5 Base address:0x8400 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:2234 errors:0 dropped:0 overruns:0 frame:0 TX packets:2234 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:168758 (164.8 Kb) TX bytes:168758 (164.8 Kb)
If you just typed /sbin/ifconfig without the -a suffix, you would not see the eth0 interface, as your network card does not yet have a valid IP address or route.
While there are many different ways to setup and subnet a network, all of them can be broken down into two types: Static and Dynamic. Static networks are setup such that each node (geek lingo for thing with an IP address) always has the same IP address. Dynamic networks are setup in such a way that the IP addresses for the nodes are controlled by a single server called the DHCP server.
5.3.1 DHCP
DHCP (or Dynamic Host Configuration Protocol), is a means by which an IP address may be assigned to a computer on boot. When the DHCP client boots, it puts out a request on the Local Area Network for a DHCP server to assign it an IP address. The DHCP server has a pool (or scope) of IP addresses available. The server will respond to this request with an IP address from the pool, along with a lease time. Once the lease time for a given IP address lease has expired, the client must contact the server again and repeat the negotiation.
The client will then accept the IP address from the server and will configure the requested interface with the IP address. There is one more handy trick that DHCP clients use for negotiating the IP address that they will be assigned, however. The client will remember it’s last assigned IP address, and will request that the server re-assign that IP address to the client again upon next negotiation. If possible, the server will do so, but if not, a new address is assigned. So, the negotiation resembles the following:
Client: Is there a DHCP server available on the LAN?
Server: Yes, there is. Here I am.
Client: I need an IP address.
Server: You may take 192.168.10.10 for 19200 seconds.
Client: Thank you.
Client: Is there a DHCP server available on the LAN?
Server:Yes, there is. Here I am.
Client:I need an IP address. The last time we
talked, I had 192.168.10.10;
May I have it again?
Server:Yes, you may (or No, you may not: take 192.168.10.12 instead).
Client: Thank you.
The DHCP client in Linux is /sbin/dhcpcd. If you load /etc/rc.d/rc.inet1 in your favorite text editor, you will notice that /sbin/dhcpcd is called about midway through the script. This will force the conversation shown above. dhcpcd will also track the amount of time left on the lease for the current IP address, and will automatically contact the DHCP server with a request to renew the lease when necessary. DHCP can also control related information, such as what ntp server to use, what route to take, etc.
Setting up DHCP on Slackware is simple. Just run netconfig and select DHCP when offered. If you have more than one NIC and do not wish eth0 to be configured by DHCP, just edit the /etc/rc.d/rc.inet1.conf file and change the related variable for your NIC to “YES”.
5.3.2 Static IP
Static IP addresses are fixed addresses that only change if manually told to. These are used in any case where an administrator doesn’t want the IP information to change, such for internal servers on a LAN, any server connected to the Internet, and networked routers. With static IP addressing, you assign an address and leave it at that. Other machines know that you are always at that certain IP address and can contact you at that address always.
5.3.3 /etc/rc.d/rc.inet1.conf
If you plan on assigning an IP address to your new Slackware box, you may do so either through the netconfig script, or you may edit /etc/rc.d/rc.inet1.conf. In /etc/rc.d/rc.inet1.conf , you will notice:
# Primary network interface card (eth0)
IPADDR[0]=""
NETMASK[0]=""
USE_DHCP[0]=""
DHCP_HOSTNAME[0]=""
Then further at the bottom:
GATEWAY=""
In this case, our task is merely to place the correct information between the double-quotes. These variables are called by /etc/rc.d/rc.inet1 at boot time to setup the nics. For each NIC, just enter the correct IP information, or put “YES” for USE_DHCP. Slackware will startup the interfaces with the information placed here in the order they are found.
The DEFAULT_GW variable sets up the default route for Slackware. All communications between your computer and other computers on the Internet must pass through that gateway if no other route is specified for them. If you are using DHCP, you will usually not need to enter anything here, as the DHCP server will specify what gateway to use.
5.3.4 /etc/resolv.conf
Ok, so you’ve got an IP address, you’ve got a default gateway, you may even have ten million dollars (give us some), but what good is that if you can’t resolve names to IP addresses? No one wants to type in 72.9.234.112 into their web browser to reach www.slackbook.org. After all, who other than the authors would memorize that IP address? We need to setup DNS, but how? That’s where /etc/resolv.conf comes into play.
Chances are you already have the proper options in /etc/resolv.conf. If you setup your network connection using DHCP, the DHCP server should handle updating this file for you. (Technically the DHCP server just tells dhcpcd what to put here, and it obeys.) If you need to manually update your DNS server list though, you’ll need to hand edit /etc/resolv.conf. Below is an example:
# cat /etc/resolv.conf nameserver 192.168.1.254 search lizella.net
The first line is simple. The nameserver directive tells us what DNS servers to query. By necessity these are always IP addresses. You may have as many listed there as you like. Slackware will happily check one after the other until one returns a match.
The second line is a little more interesting. The search directive gives us a list of domain names to assume whenever a DNS request is made. This allows you to contact a machine by only the first part of its FQDN (Fully Qualified Domain Name). For example, if “slackware.com” were in your search path, you could reach http://store.slackware.com by just pointing your web browser at http://store.
# ping -c 1 store PING store.slackware.com (69.50.233.153): 56 data bytes 64 bytes from 69.50.233.153 : icmp_seq=0 ttl=64 time=0.251 ms 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max = 0.251/0.251/0.251 ms
5.3.5 /etc/hosts
Now that we’ve got DNS working fine, what if we want to bypass our DNS server, or add a DNS entry for a machine that isn’t in DNS? Slackware includes the oft-loved /etc/hosts file which contains a local list of DNS names and IP addresses they should match to.
# cat /etc/hosts 127.0.0.1 localhost locahost.localdomain 192.168.1.101 redtail 172.14.66.32 foobar.slackware.com
Here you can see that localhost has an IP address of 127.0.0.1 (always reserved for localhost), redtail can be reached at 192.168.1.101, and foobar.slackware.com is 172.14.66.32.
5.4 PPP
Many people still connect to the Internet through some kind of dialup connection. The most common method is PPP, though SLIP is still occasionally used. Setting up your system to speak PPP to a remote server is pretty easy. We’ve included a few tools to help you in setting it up.
5.4.1 pppsetup
Slackware includes a program called pppsetup to configure your system to use your dialup account. It shares a look and feel similar to our netconfig program. To run the program, make sure you are logged in as root. Then type pppsetup to run it. You should see a screen like this:
The program will present a series of questions, to which you will feed it appropriate answers. Things like your modem device, the modem initialization string, and the ISP phone number. Some items will have a default, which you can accept in most cases.
After the program runs, it will create a ppp-go program and a ppp-off program. These are used to start and stop, respectively, the PPP connection. The two programs are located in /usr/sbin and need root privileges to run.
5.4.2 /etc/ppp
For most users, running pppsetup will be sufficient. However, there may be an instance where you want to tweak some of the values used by the PPP daemon. All of the configuration information is kept in /etc/ppp. Here is a list of what the different files are for:
ip-down
This script is run by pppd after the PPP connection is ended.
ip-up
This script is run by pppd when there’s a successful ppp connection. Put any commands you want run after a successful connection in this file.
options
General configuration options for pppd.
options.demand
General configuration options for pppd when run in demand dialing mode.
pppscript
The commands sent to the modem.
pppsetup.txt
A log of what you entered when you ran pppsetup.
Most of these files won’t be there until after you run pppsetup.
5.5 Wireless
Wireless networking is still a relatively new thing in the world of computers, yet is quickly catching on as more people begin to purchase laptops and want networking on the go, without having to fool with some old twisted pair cable. This trend doesn’t appear to be slowing down. Unfortunately, wireless networking isn’t yet as strongly supported in Linux as traditional wired networking.
There are three basic steps to configuring an 802.11 wireless Ethernet card:
-
Hardware support for the wireless card
-
Configure the card to connect to a wireless access point
-
Configure the network
5.5.1 Hardware Support
Hardware support for a wireless card is provided through the kernel, either with a module or built in to the kernel. Generally, most newer Ethernet cards are provided through kernel modules, so you’ll want to determine the appropriate kernel module and load it through /etc/rc.d/rc.modules. netconfig may not detect your wireless card, so you’ll probably need to determine the card yourself. See http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/ for more information on kernel drivers for various wireless cards.
5.5.2 Configure the Wireless Settings
The vast majority of this work is done by iwconfig, so as always read the man page for iwconfig if you need more information.
First, you’ll want to configure your wireless access point. Wireless access points vary quite a bit in their terminology, and how to configure them, so you may need to adjust a bit to accommodate your hardware. In general, you’ll need at least the following information:
-
The domain ID, or name of the network (called the ESSID by iwconfig)
-
The channel the WAP uses
-
The encryption settings, including any keys used (preferably in hexadecimal)
A NOTE ABOUT WEP. WEP is quit flawed, but it’s much better than nothing. If you wish a greater degree of security on your wireless network, you should investigate VPNs or IPSec, both of which are beyond the scope of this document. You might also configure your WAP not to advertise its domain ID/ ESSID. A thorough discussion of wireless policy is beyond the scope of this section, but a quick Google search will turn up more than you ever wanted to know.
Once you’ve gathered the above information, and assuming you’ve used modprobe to load the appropriate kernel driver, you can edit rc.wireless.conf and add your settings. The rc.wireless.conf file is a bit untidy. The least effort is to modify the generic section with your ESSID and KEY, and CHANNEL if required by your card. (Try not setting CHANNEL, and if it works, great; if not, set the CHANNEL as appropriate.) If you’re daring, you can modify the file so that only the necessary variables are set. The variable names in rc.wireless.conf correspond to the iwconfig parameters, and are read by rc.wireless and used in the appropriate iwconfig commands.
If you have your key in hexadecimal, that’s ideal, since you can be fairly confident that your WAP and iwconfig will agree on the key. If you only have a string, you can’t be sure how your WAP will translate that into a hexadecimal key, so some guesswork may be needed (or get your WAP’s key in hex).
Once you’ve modified rc.wireless.conf, run rc.wireless as root, then run rc.inet1, again as root. You can test your wireless networking with standard testing tools such as ping, along with iwconfig. If you have a wired interface you may wish to use ifconfig to turn those interfaces off while you test your wireless networking to ensure there’s no interference. You may also want to test your changes through a reboot.
Now that you’ve seen how to edit /etc/rc.d/rc.wireless for you default network, let’s take a closer look at iwconfig and see how it all works. This will teach you the quick and dirty way of setting up wifi for those times when you find yourself at an Internet cafe, coffee shop, or any other wifi hot spot and wish to get online.
The first step is to tell your wireless NIC what network to join. Make sure you replace “eth0” with whatever network interface your wireless card uses and change “mynetwork” to the essid you wish to use. Yes, we know you’re smarter than that. Next you’ll have to specify the encryption key (if any) used on your wireless network. Finally specify the channel to use (if needed).
# iwconfig eth0 essid "mynetwork" # iwconfig eth0 key XXXXXXXXXXXXXXXXXXXXXXXXXXX # iwconfig eth0 channel n
That should be all on the wireless end of things.
5.5.3 Configure the Network
This is done in the exact same way as wired networks. Simply refer to earlier sections of this chapter.
5.6 Network File Systems
At this point, you should have a working TCP/IP connection to your network. You should be able to ping other computers on your internal network and, if you have configured an appropriate gateway, you should also be able to ping computers on the Internet itself. As we know, the whole point in bringing a computer onto a network is to access information. While some people might bring a computer up on a network just for the fun of it, most people wish to be able to share files and printers. They wish to be able to access documents on the Internet or play an online game. Having TCP/IP installed and functional on your new Slackware system is a means to that end, but with just TCP/IP installed, functionality will be very rudimentary. To share files, we will have to transfer them back and forth using either FTP or SCP. We cannot browse files on our new Slackware computer from the Network Neighborhood or My Network Places icons on Windows computers. We’d like to be able to access files on other Unix machines seamlessly.
Ideally, we’d like to be able to use a network file system to allow us transparent access to our files on other computers. The programs that we use to interact with information stored on our computers really do not need to know on what computer a given file is stored; they just need to know that it exists and how to get to it. It is then the responsibility of the operating system to manage access to that file through the available file systems and network file systems. The two most commonly used network file systems are SMB (as implemented by Samba) and NFS.
5.6.1 SMB/Samba/CIFS
SMB (for Server Message Block) is a descendant of the older NetBIOS protocol that was initially used by IBM in their LAN Manager product. Microsoft has always been fairly interested in NetBIOS and it’s successors (NetBEUI, SMB and CIFS). The Samba project has existed since 1991, when it was originally written to link an IBM PC running NetBIOS with a Unix server. These days, SMB is the preferred method for sharing file and print services over a network for virtually the entire civilized world because Windows supports it.
Samba’s configuration file is /etc/samba/smb.conf; one of the most well commented and documented configuration files you will find anywhere. Sample shares have been setup for you to view and modify for your needs. If you need even tighter control the man page for smb.conf is indispensable. Since Samba is documented so well in the places I’ve mentioned above, we will not rewrite the documentation here. We will, however, quickly cover the basics.
smb.conf is broken down into multiple sections: one section per share, and a global section for setting options that are to be used everywhere. Some options are only valid in the global section; some are only valid outside the global section. Remember that the global section can be over-ridden by any other section. Refer to the man pages for more information.
You will most likely wish to edit your smb.conf file to reflect the network settings in your LAN. I would suggest modifying the items listed below:
[global] # workgroup = NT-Domain-Name or Workgroup-Name, eg: LINUX2 workgroup = MYGROUP
Change the workgroup name to reflect the workgroup or domain name that you are using locally.
# server string is the equivalent of the NT Description field server string = Samba Server
This will be the name of your Slackware computer displayed in the Network Neighborhood (or My Network Places) folder.
# Security mode. Most people will want user level security. See # security_level.txt for details. NOTE: To get the behaviour of # Samba-1.9.18, you'll need to use "security = share". security = user
You’ll almost certainly wish to implement user level security on your Slackware system.
# You may wish to use password encryption. Please read # ENCRYPTION.txt, Win95.txt and WinNT.txt in the Samba # documentation. # Do not enable this option unless you have read those documents encrypt passwords = yes
If encrypt passwords is not enabled, you will not be able to use Samba with NT4.0, Win2k, WinXP, and Win2003. Earlier Windows operating systems did not require encryption to share files.
SMB is an authenticated protocol, meaning you must supply a correct username and password in order to use this service. We tell the samba server what usernames and passwords are valid with the smbpasswd command. smbpasswd takes a couple of common switches to tell it to either add traditional users, or add machine users (SMB requires that you add the computers’ NETBIOS names as machine users, restricting what computers one can authenticate from).
Adding a user to the /etc/samba/private/smbpasswd file. # smbpasswd -a user Adding a machine name to the /etc/samba/private/smbpasswd file. # smbpasswd -a -m machine
It’s important to note that a given username or machine name must already exist in the /etc/passwd file. You can accomplish this simply with the adduser command. Note that when using the adduser command to add a machine name one must append a dollar sign (“$”) to the machine name. This should not however, be done with smbpasswd. smbpasswd appends the dollar sign on its own. Failing to mangle the machine name this way with adduser will result in an error when adding the machine name to samba.
# adduser machine$
5.6.2 Network File System (NFS)
NFS (or Network File System) was originally written by Sun for their Solaris implementation of Unix. While it is significantly easier to get up and running when compared to SMB, it is also significantly less secure. The primary insecurity in NFS is that it is easy to spoof user and group id’s from one machine to another. NFS is an unauthenticated protocol. Future versions of the NFS protocol are being devised that enhance security, but these are not common at the time of this writing.
NFS configuration is governed by the /etc/exports file. When you load the default /etc/exports file into an editor, you’ll see a blank file with a two line comment on top. We’ll need to add a line to the exports file for each directory that we wish to export, with a listing of client workstations that will be allowed to access that file. For instance, if we wished to export directory /home/foo to workstation Bar, we would simply add the line:
/home/foo Bar(rw)
to our /etc/exports. Below, you’ll find the example from the man page for the exports file:
# sample /etc/exports file / master(rw) trusty(rw,no_root_squash) /projects proj*.local.domain(rw) /usr *.local.domain(ro) @trusted(rw) /home/joe pc001(rw,all_squash,anonuid=150,anongid=100) /pub (ro,insecure,all_squash)
As you can see, there are various options available, but most should be fairly clear from this example.
NFS works under the assumption that a given user on one machine in a network has the same user ID on all machines across the network. When an attempt is made to read or write from a NFS client to an NFS server, a UID is passed as part of the read/write request. This UID is treated the same as if the read/write request originated on the local machine. As you can see, if one could arbitrarily specify a given UID when accessing resources on a remote system, Bad Things ™ could and would happen. As a partial hedge against this, each directory is mounted with the root_squash option. This maps the UID for any user claiming to be root to a different UID, thus preventing root access to the files or folders in the exported directory. root_squash seems to be enabled by default as a security measure, but the authors recommend specifying it anyway in your /etc/exports file.
You can also export a directory directly from the command line on the server by using the exportfs command as follows:
# exportfs -o rw,no_root_squash Bar:/home/foo
This line exports the /home/foo directory to the computer “Bar” and grants Bar read/write access. Additionally, the NFS server will not invoke root_squash, which means any user on Bar with a UID of “0” (root’s UID) will have the same privileges as root on the server. The syntax does look strange (usually when a directory is specified in computer:/directory/file syntax, you are referring to a file in a directory on a given computer).
You’ll find more information on the man page for the exports file.
Tags: account, catch, domain, domain name, ftp, manage, password, slackware, Slackware Linux Essentials, software, ssl