Setting up a basic home network with Slackware 10.1
 

A quick and dirty guide to setting up a basic home network with Slackware 10.1



PREAMBLE

This posting is a sort of mini-howto on setting up a basic home network with Slackware 10.1. I'm writing this up in the hope that the information will be of use to others in the same situation but without making any guarantees. I classify myself as a network newbie and most of the stuff I'm talking about below even I don't necessarily understand fully. All I can say about this is that it worked for me on my hardware, whether or not it will work on another set-up I am not qualified to say except that, apart from getting Linux to recognise the network cards, I don't see why it shouldn't. Also note that I'm simply writing up what worked for me, it isn't necessarily the correct way or the best way and certainly not the most secure way but it worked. Other than that I make no claims for these instructions. If this info is of use to you please feel free to let me know by posting to this thread.



THE PROBLEM

At present I three PC's at home, all used only for personal and training purposes. They are (i) a 2.2GHz Sempron with a Microsoft-free 200Gb hard-drive, (ii) an ageing 350MHz, dual-boot AMD K6 III with a 20Gb hard-drive of which 3Gb is in use by Windows 98 and the rest by Linux and (iii) a 1GHz laptop with a 20Gb hard-drive devoted exclusively to Windows XP (but that's soon about to change!). What I wanted to do was set up my Sempron as a network server that allowed part of its hard-drive to be shared by the other computers in the network. For the moment I wanted to concentrate solely on getting the other Linux box reading the shared directory as connecting the laptop would mean that I would have to set-up and configure Samba, and, being a network newbie, I decided to start off by getting the two Linux boxes talking.

My main motivation for writing this posting comes from the fact that I was not able to find any how-to on setting up this network. Most of the resources were specific to one distro and did not work for Slackware, it was only after many hours of running down-dead ends and postings to the SLUG mailing list that I was finally able to get my Linux boxes talking to each other. I am therefore writing this in the hope that others can have an easier time of it. My thanks go out to Matthew Macdonald-Wallace, Steve Dobson and John Crowhurst without whom this write-up would never have been possible.



THE PRE-REQS

For the purposes of this how-to I will make certain basic assumptions:

(i) You are comfortable with the command-line.

All the work I will do here is with the command line, the X-server never got a look-in. If you do prefer to use a GUI then read on anyway. In theory, everything you can do on the command-line should be possible with the GUI, just don't expect me to know how it's done.

(ii) You know basic Linux commands and the file system.

Most of what follows is editing text files and entering a few basic commands. I am a network newbie, as I have said, but I have been using Bash for some years and am comfortable with the more basic commands, though I'm not a Bash programmer by any means. If you understand commands like "ps -A | grep nfsd" or "ls -ld /home/public" then you should be OK.

(iii) You are running Slackware 10.1.

This how-to is written specifically and only for Slackware 10.1, we will start with a basic, virgin installation from DVD. Other distros uses different filesystems so it probably won't work with those. As for earlier versions of Slackware, I don't know, please feel free to tell me by posting on this thread.

(iv) You are a networking newbie.

I am a long way off from being any kind of authority or guru, I'm just doing a write-up of my experiences as a networking newbie getting his feet wet in the big, bad world of networking. One problem I faced is with the terminology used, often words and concepts were spoken of as if they were "everybody-knows"-type terms. Yes, maybe everybody does know, except me. Therefore in this write-up I am going to try to explain each new concept in newbie-friendly terms so, for those of you who know their stuff, sorry if I'm being a bit pedantic with my terminology.



THE BASICS

First lets outline the hardware necessities. I've given you the basic hardware info above. Both machines have had fairly fresh installations of Slackware 10.1, have had little changes to their default set-up and were installed with all but the international characters package selected and a full install done. Both machines have network cards but nothing fancier than the one built into the motherboard. The cards are connected to a cheap, 8-port switch, though I did check the reviews to ensure that it could be used with Linux. The network cards do not have any lights connected to them to tell me if the hardware recognises the existence of a physical line but the switch has all the relevant lights on so the hardware seems happy. All that remains is to set up the software to go with it.

From this point on I will frequently refer to Chapter 5 of the Slackware on-line book. This write-up is not intended as a replacement for that book but rather as a supplement to it to comment on things that I found were missing from there.



THE TASK

OK, so let's outline exactly what we want to achieve. On the Sempron, I have a 200Gb hard-disk which is begging to be used, therefore setting it up as a server with part of the hard-drive visible and available to all the other machines seems like a good place to start. The first step is to create that shared directory. By the way, everything I'm doing here is done as root, I haven't bothered to check but probably most if not all of the files that need to be altered can only be changed by root so just make sure that everything here is done by root. The shared directory itself I have decided call /srv/public and grant read/write access across the network. You may not have seen the /srv directory before and by default Slackware does not create it, for for a full discussion of what this directory means and what it is used for see the Filesystem Hierarchy Standard. To create this directory, use the following commands:

These create the directory and let it be read from and written to by all users. Now that that is done we need to decide how to set the network up and what we will call it. For my system, the Sempron, which I am using as the server, will be called "templeofthebeard" while the AMD K6 III, the client, will be called "shrineofthebeard". Of course, this name is totally made up and you can chose any name you want to. The server itself I will call homenet which is the name of the network that templeofthebeard and shrineofthebeard are connected to. As there is only two machines on the network at present we don't need to get more complicated than that. Therefore, as far as the network is concerned, the server is officially called templeofthebeard.homenet while the client is called shrineofthebeard.homenet.



THE MAGIC NUMBER

Now we need to decide on what IP numbers we will assign to the machines. This is one area I had a lot of trouble with. At first I saw that the IP address assiged to "Localhost" was given as 127.0.0.1, therefore I assumed that that was a domain I could work with. Well several hours later I discovered what 127.0.0.1 actually meant (or at least got a functional definition for it) and out that I was running down a dead end, which brings me to the Magic Number - 192.168.x.x. In the Slackware book this number appears on the second page of Chapter 5 without commentary. I had originally thought that the author had his computer connected to the Internet and his own web address was 192.168.1.10. However, after a lot of digging around the web, I did finally find what the number meant (though to be honest I don't remember where). 192.168.x.x is a reserved address for setting up private networks that are not accessible to the 'net (note: this is not a technical definition and is only based on my understanding of a web-page that I read once and forgot the name of). When you are setting up a home network these are the numbers to be used. The first x refers to the subnet name in cases where you have several networks connected in one system while the second x is the number of the machine proper. Using this info we can now assign appropriate IP addresses to the two machines. I chose 192.168.1.1 for the server and 192.168.1.2 for the client. Using this we can now start to configure the network.

For now I am working only on the server as that takes the most work, the client is much easier to set-up once the server is going. Run the command "netconfig", this is an ncurses-based program used to configure the network settings. First you will be asked for the hostname. Enter "templeofthebeard" (or whatever name you choose), now it will ask for the domain name, in my case this is "homenet". I then chose "static IP" as I only running internal network with no connection to the Internet so static IP is the one to choose here. Next you will be asked for the IP address, by default it will be 127.0.0.1, which is what threw me when I first saw it - this is not what you want. Change it to 192.168.1.1. Next you will be asked for the "NETMASK", if you want to know what this means, ask someone who knows, I don't fully understand the concept behind it. However the default value of 255.255.255.0 should be fine. Then leave the gateway line blank and choose "no" when asked for a nameserver. Finally, review your choices to ensure you have made no typos and press accept. You have just finished the first step.



THE NETWORK CARD

Now we need to ensure that our network cards are working. Type "ifconfig" into the console. Hopefully you will see something like this (note that the actual outut will be indented, this system removes the whitespacing from this posting):


If you do, good. It means that your network is running OK and is ready to use, if not don't worry, type "ifconfig eth0" and hopefully you will see something like this:

This is essentially the same as above but with the second line missing. All that means is that the card is configured correctly but is not broadcasting on the network, on the other hand if you get an error message then consult the Slackware book for more info, here I'm going to assume that the card is configured correctly as trouble-shooting an unconfigured card is beyond my means right now. OK, so the card is configured but not broadcasting, to fix that type the following command: The IP number you know now about but what about "broadcast 192.168.1.255?" Well, and again this is from a network novice (which is only one step up from a network newbie), the 255 is a general, system-wide call. The card will now broadcast to the whole 192.168.1.x range, i.e. it would broadcast to all computers on the 192.168.1 network. Were you to change it to "broadcast 192.168.255.255" it would broadcast to all computers on all networks in the 192.168 domain, get the idea? Now you should see entries for both "lo" and "eth0" when you type "ifconfig." By the way, the lo refers to a loopback device which, for those of you who don't know, and I didn't until about two days ago, is a software device that allows certain programs to network back to the machine their on, which is why if you type "ping 127.x.y.z" where x, y and z are any numbers between 0 and 254 you seem to get a sensible response. What's responding is the loopback device, not an external network.



CONFIGURING THE SERVER

Now we need to edit some files. First on the list is /etc/hosts which provides a basic DNS server for the network. By default, netconfig will have edited this to read as follows (minus commented lines):

The first line we've covered, the second line is the IP address of the server but it also has the additional entry "templeofthebeard" by itself. That means that we can call the machine by simply calling it "templeofthebeard" without adding the ".homenet" to it every time. We now need to manually add a look-up entry for the client, add the following line: "192.168.1.2 shrineofthebeard.homenet" to the file. Now when call the client by either it's full name or by the shortened version the computer will be able to see what we are talking about.

In the Slackware book the author also talks about altering the /etc/inetd.conf and /etc/resolv files. Personally I found I did not need to alter these (not yet at least), all I want to do is share a directory and the network is small enough to allow the DNS services to be run via /etc/hosts. Next the author talks about the /etc/rc.d/rc.inet1 and /etc/rc.d/rc.inet2 files. Personally, I merely skimmed through these files making sure that the line to activate the portmap, nfsd and mountd files were not commented out which they weren't by default. However here I hit two trouble areas, the first was that the portmap and nfsd programs were not called that, they are called rpc.portmap and rpc.mountd. Also if you look in the rc.inet2 file and look for a section of the code that starts with the commented line "# Load the RPC portmapper if /etc/rc.d/rc.portmap is executable." you will see that it tries to run the file /etc/rc.d/rc.portmap. However, by default, that file it not executable. Rather than getting into the question of whether the daemon is actually needed or not I decided to take the easy way out and follow the advice of the Slackware book and made /etc/rc.d/rc.portmap executable. Whether or not this is executable by default I think depends upon what options you choose at installation time for what services are run at boot-time.

The next file to look at is /etc/rc.d/rc.inet1.conf. Here you will see lots of entries for several network cards but the entries should be null by default if you only have one network card. You are interested in the lines that read "IPADDR[0]="192.168,1.1"" and "NETMASK="255.255.255.0"". If these settings are per your own defined set-up then OK, this file should not need modifications.

Finally we need to make the /srv/public directory available in the network. Open the /etc/exports file. By default there should be no uncommented lines so add the following line to it: This allows shrineofthebeard.homenet to access /srv/public while for an explanation of what the options type "man exports" but be warned that it is not very newbie friendly.

At this point I would reboot the server so that all these changes can take effect. I'm sure there's a better way of doing this but this one will do for now! As it reboots, keep an eye on the screen output for any error messages associated with the nfsd or the rpc portmapper, etc. If there are none then all should be fine.

OK, that should be it. Now we need to configure the client machine.



CONFIGURING THE CLIENT

This one is more straightforward, there is a lot less to do and much of it is the same as what we covered on the server. For starters the /etc/hosts should look exactly the same, while netconfig is also very similar but with the values "shrineofthebeard" and "192.169.1.2" in place of "templeofthebeard" and "192.169.1.1." Likewise with the commands for setting up the network card.

Once the network card is in place you should be able to ping the server. Type "ping templeofthebeard" and see what you get. You should see something like this:

If so, good, your network is almost ready! Press [CRTL-C] to stop ping. If this does not work then go back through everything above and check all the config files, make sure you've entered the data correctly and there are no typos, I had quite some trouble with this myself. If you've done that and you still can't ping the server then feel free to post a query on this thread, I may not know the answer myself but I would like to know if there was something I overlooked or got wrong in this write-up and will be only too happy to make whatever amendments are necessary.

Now we need somewhere to mount the server directory. This way we can use the shared directory as though it were part of the clients filesystem. On my system I've chosen to mount the directory onto /home/shared. Create this with "mkdir /home/shared." Now, type the command "mount -t nfs templeofthebeard.homenet:/srv/public /home/shared." If all is well, the command prompt will return without any messages and your network is ready! As a final point, in order to have this directory at boot time add the following line to /etc/fstab "templeofthebeard.homenet:/srv/public /home/shared nfs defaults 0 0."



REQUEST FOR FEEDBACK

Well, that's it for this. I hope that this has been of use to you. As I have said I just a networking novice, my usual philosophy in life is to get something going to start off with and then worry about the fine details. How that applies here is that the above is probably insecure and inelegant but it is one way of doing it. Once you know that your network does work you can then work on improving it, adding extra services, making it more secure, etc. That is the point I am at now. Please let me know if this posting has been of use to you. This is the first time I've ever written any kind of how-to so I'd like to know if it helps anybody. Also I plan to put several more machines onto the network, including an XP laptop which will require a Samba server, and then connect the server to the web so that I can run my own website from it. If this posting gets good feedback then it will probably be worth my time writing-up the rest of my actions. Also I can't guarantee that I got all the details correct, I'm fairly certain everything is in order and that there are no typos here but if you see any let me know, also if you've followed the instructions given and you failed to get the server running let me know too. Consider this write-up work-in-progress.



Ver. 1.1.1
Created: 02 May 2005, 07:53GMT
Last update: 02 May 2005, 22:25GMT

According to FHS, I believe that data which is shared over a network should go in a subdirectory of /srv, like /srv/public, instead of /home/public. /home/public would be data shared only on that specific machine.

Nice tutorial but
- /etc/exports could be more shown like put it in [ code ] [ /code ] markup
also I recommand using hard,intr as nfs options. The option no_root_squash is
dangerous as any client can remove, overwrite files owned by root and nfs
client does not have to login to access nfs share

- You did not mention the possibility to share a directory without editing /etc/exports :
/usr/sbin/exportfs client:/path/to/shared_dir

- You could indicate that nfs trnasfer can be faster with these client options :
rsize=8192,wsize=8192

- Permissions could be a problem if uid or gid don't match between client and server
so in this case, one could use as options in /etc/exports:
all_squash,anonuid=500,anongid=100

- Also to check the nfs shares :
/usr/sbin/showmount -e server

I found it a very interesting read, thanks for taking the time to write it.

If the more experienced users add input I think this can become a valuable starting point for people like me who are trying to do similar projects.

Thanks for posting it :)

well....that was just way to much text for me.
and a lot of the needed info is embedded in it, so it's hard to find a specific item back.

you could cut down on the text by leaving out your hunt for info,
and show the things that matter in a form of lists and small alineas.

i don't think it's wise to write tutors about subjects you don't understand
if you don't know what a netmask is or what address-ranges are to be used for subnets,
do some reading on that first.
if you just google for "ip address range " you'll get lots of info.

as a side note : you don't need to reboot at any time to set it all up.
( a reboot is only needed when you change to another kernel. )

my choice " too much text, too less info " is not on the list.
but if you would cut most of the text and get the instructions lined up without adding more info,
i think it would be called a "quick & dirty " guide.
those are for people that just want to get things working without bothering about the " why "
nothing wrong with that.

egag

uselpa wrote:

Corrected, explanatory link included.

keefaz wrote:

Done.

Under consideration, I need to research what that means for the next version. :)

The network was only ever intended to be used by one person for research/training purposes so security was not an issue. The wording of the /etc/exports setting was written verbatim from a mailing list submission without me actually understanding what it meant. Having read the man page for exports, I now see that it is probably unnecessary in this instance therefore that option has been removed. However I have not tested the network yet so I can't guarantee that it will still work, though I see no reason why it shouldn't.

That's because I didn't know about it. Thank you for the info. I shall look into this more thoroughly when I have time and probably write a more refined version of the posting. I'm already considering writing Part II: From Networking Novice to Webmaster!


Sorry, I have no idea what all that means! Consider that to be in the same category as above.


chefmark wrote:

You're very welcome.

That does seem to be ocurring, albeit slowly.


egag wrote:

Point well taken, I've stripped it down considerably and made it more legible, hope you like the changes.

I was filling a void. I spent many hours reading how-to's, web-pages, books, etc, etc, a lot of these turned out to be dead ends. The info on what 192.168 meant I only found in one source, though I saw the number being used in lots of places without explanation. No, perhaps I don't know what a netmask is, but I do know that using the default number of 255.255.255.0 works. One of the problems with this kind of work is that there is an overwhelming amount of data that could be studied and it's almost impossible to know which things you need to read and study up on which you can get by without knowing. My qualifications on this matter are that I hacked something together that worked and when I was done I re-formatted my hard-drive and did it all over again just to prove to myself that I could do it. The posting is write-up of what I did to get two Linux boxes talking to each other, not an hatting manual on system administration.

True, but I had made so many unnecessary changes and had so many copies of the same daemon running that it seemed the safest option. Also certain text files are only used when a daemon is loading and changes to it are ignored unless the daemon is restarted. Rather than try to find out what alterations require what daemon to be restarted, I thought it would be simpler to do a catch-all reboot.

Thank you for the suggestion, see the name change and the shortened text and tell me if this is more to your liking. :)



Thank you to everyone who took the time out to read my write-up and suggest the changes outlined above. Please feel free to suggest any more alterations (without getting too technical) or improvements.

showmount is very usefull as it shows exported directories for a host, so you can
mount nfs share with no problem if showmount shows all shares.

It is like ping tool when you set up a network, when you setup NFS, you use
showmount intensivly.

Anyway congrat for your tutorial and for your energy you employed to it, sincerlly