Linux Networking 101
As with all JWG Tutorials, screenshots are provided within the JWG Gallery, to make following the tutorials easy for beginners.
The simplest method of viewing the screenshots along with the tutorials, is to right click on the first screenshot, and choose ‘open in new window or tab’, depending on your browser preferences. Then you can keep this new window or tab open, and browse through the screenshots in the gallery itself, by clicking on the next arrows on the right of the gallery screen.
Network configuration
It is assumed that your computer is already physically network-enabled as described in Tutorial 1:Installation, with cables, NIC, (Network Interface Card), modem/router in place, and that our task here is to configure the software to create a small private network. Internet connectivity can be added later, if required. A detailed discussion of this is outside the scope of this section of my linux guides, but will be explored in a later tutorial which looks at the wider concept of networking and operating systems
During the initial installation process of OpenSuSE 10.2 as documented in Tutorial 1:Installation, a new local user with it’s own unique password was created in addition to the Root user. We are now going to boot up the computer, and when the graphical login screen comes up, login as this user. This brings you to the desktop.
As we are going to do much of our network configuring through the YAST interface, it will be useful to create a shortcut to this on the desktop. For our purposes we are using the KDE desktop, so open the KDE Menu (a Blue K with an arrow at bottom left of the desktop, (where you would find the Windows Start Menu). Navigate to System: YAST Control Center. Right click on YAST Control Center, and click on Add Item to Desktop. Subsequently, you will be able to access the YAST Control Center via the desktop. You can create desktop shortcuts of any programs you use frequently, in this way, just as you would in Windows.
Open the YAST Control Center (henceforward to be referred to as simply YAST), and go to Network Devices and then Network Card. You will be asked for the root password to continue.
This will happen every time you open YAST, because making system changes requires administrator (root) privileges. The root user and password were created at the start of the installation process, and it is this password that you put in now, NOT your user password that you supplied to login. Although this may seem initially confusing compared to Windows logons, you will quickly get used to it and will be able to type the root password in your sleep!
Choose User controlled with Network Manager as your preferred Network Setup method, and click next. YAST will have detected that a network card is installed and it will appear here. However, by default it will have assigned it an IP address that is automatically configured by DHCP (Dynamic Host Configuration Protocol). As our small, peer to peer network does not have a DHCP server (more on this later), we need to assign each of the computers in our network an individual Static IP address. To do this, click on the network card and then Edit.
The Network Address Setup window opens. Put a check in the box for Static Address Setup, and fill in your IP Address, (See Tutorial 3 for a brief explanation of TCP/IP and IP Addresses).
As can be seen in screenshots 1, 2 and 3, the computer in our example has a private, non-routable IP address of 192.168.5.40, which means it is machine number 40 in the network 192.168.5.0 and has a subnet mask of 255.255.255.0 indicating that it is in a Class C Network.
Click on Hostname and Name Server:
Fill in the Hostname, (this is the name of your computer, and may be automatically assigned by SuSE as in the example in screenshot 4, or you can choose a more descriptive name yourself.
The Domain Name has been chosen to be the same as the workgroup in the Windows 98 network set up in Tutorial 4 (test-lan), simply for ease of administration when setting up the SAMBA system to allow Windows and Linux to talk to each other.
It has the addition of the TLD (Top Level Domain) of .local because Linux systems require a domain name to be an FQDN (Fully Qualified Domain Name).
.local is a private, non Internet –facing domain name, which may be used in private networks, thus avoiding the need to purchase and register a public domain name like microsoft.com… or bbc.co.uk.
At this point, we are only putting in one name server, which is that of localhost or the loopback address, (see Tutorial 3), but if our computer was situated in a network that was running an internal, non-Internet- facing Domain Name Server (DNS Server), it would receive it’s name servers from that machine instead. We put our domain name into the Domain Search box, and click ok.
This takes us back to the Network Address Setup screen.
For our current task, the routing and advanced buttons are not relevant to us, as they are concerned with the default gateway and hardware details, which are also discussed briefly in Tutorial 3. Click Next, all your changes will be saved, and you will returned to the YAST main window.
Users and Permissions:
One of the main differences between Linux and Windows is that the concept of users, file ownership and permissions is inherently more fundamental in Linux. One can set much more specific and finely tuned permissions for users and files in Linux. It is also worth noting that getting these wrong is the cause of a considerable number of network problems, so it is important to have a basic understanding of these issues before actually networking our computers.
Linux is a multi-user operating system, therefore, some files will need to be available to all users, and some system files will need to be accessible only by those with Admin rights. Each user will need unrestricted access to all the files in their own Home directory, (a rough equivalent of ‘My Documents’ in Windows), whilst access to another user’s Home directory must be unavailable or restricted in some way. All this is achieved by creating user and group accounts, and setting the desired permissions for each user and group. Each user can be given specific access to certain files, but will also be part of at least one user group where access to other files is shared by all members of a group. For example: user Jon has full ownership of all the files in his Home directory, and user Leo has full ownership of all the files in his Home directory. Neither user can access each other’s files, but they are both members of group Saturn. All the members of group Saturn have access to the files in the usr/share directory, so both Jon and Leo can access these files.
When we talk about access permissions, there are in fact 3 different types of permission, which can be defined as read, write and execute.
Read allows a file to be read (viewed) only. Write allows a file to be written to, (altered or deleted). Execute (X), allows a program or script to be executed (run). This is equivalent to directory access.
There are also 3 categories of file owner, User, Group and Other.
User refers to the file owner, (usually the file creator, but the Root user or System Admin, can also change file ownership). Users can belong to one or more Groups, and Other includes all other users who are not the file owner or in the file owner’s Group.
The table in the next screenshot shows how these permissions work in practice.
The numbers are then added up for each category to arrive at the relevant numeric position. Numeric Mode permissions are often used in Linux and web servers in particular, and the most frequently used tend to be memorised (e.g. 644 and 755 for web pages).
Therefore, we are going to create the user accounts for our network before we do anything else. This is to ensure that we create identical users on each computer in our network. This is crucial for networking to work. If anything about a user is not completely identical on both machines, the computers will not connect. It is as simple and basic as that.
You should still have the YAST window open. If not, click on the icon on the desktop to open it. You will be asked for the root password again. Click on Security and Users, and then User Management.
The User and Group Administration window opens:
As can be seen in screenshot 5, the user that is currently logged in (you), will appear and be highlighted. If you click Edit, you will notice 3 tabs. The first tab is User Data which will show your username, real name and password in asterisks. If you wish to change any of this information, you may do so at this point.
The second tab is Details. If you click on this, the following screen appears:
On this screen we have UserID (uid) which, as mentioned previously, is highly important. By default, SuSE assigns 1000 to the first user it creates. This is all very well on a stand-alone computer, but if a network is being setup, each user cannot have the same uid. As our computer is the first to be setup in the network, we can leave this uid alone, but the users on all other computers to be added to our subnet, WILL need to have their UserID changed to something different BEFORE they are added to the network. This can be accomplished on each computer by navigating to this screen, and changing the uid from 1000 to another number.
On this screen we can also see where our home directory is, (/home/julia in this example), and a list of Groups. A user is assigned the Users group as default, and is also a member of 2 other groups, dialout and video, but can be added to any others in the list if desired. The 3rd tab refers to password settings, and does not need to be changed at this point. Click Accept, and you will return to the main User Admin screen.
We will assume that the UserIDs have been changed on the other network computers as described above, and so we can add these users to our computer now. Click Add, and the New Local User window opens, which is identical to the edit screen, except that all the fields are blank. Add each user’s details, in the User Data tab, and then click on the Details tab where you must change the uid (which will have been automatically created as 1001), to the actual uid of your users. Add each user individually, and then you should have a list of users similar to the one below.
I have just added two users in this example, but obviously you would add all the users in your subnet here. This process needs to be repeated on ALL computers in the subnet, so that this screen is identical on every machine. If your subnet is quite large (even Class C subnets can have up to 254 separate users in them), this would prove to be rather a tedious, time consuming undertaking, but there is a mechanism for automating this procedure known as the Network Information Service (NIS), and this will be discussed later.
NFS File Sharing:
We are now ready to set up a file sharing system between the computers in our network, and to begin with, we will do this using the Network File System (NFS). In a small peer to peer network such as the one we are setting up, each computer needs to be configured as both an NFS Server and an NFS Client. The NFS system enables the computers to both send and receive files across the network.. This client/server relationship only exists for the purposes of file sharing, and is not be confused with an actual client/server network, which again, will be discussed later in this guide.
NFS Server:
We begin by configuring the NFS Server. In YAST, go to Network Services, NFS Server, and Start the Server. Click Next, and this is where you choose the directories to export to (share with), other users on the network. How you choose the directories you wish to share will vary depending on the type of network, but for this example I have created a Shared directory within the home directory of the initial user julia, ( /home/julia/Shared). All files that are placed in this directory will be able to be shared across the network.
Further directories to be shared may be added, if needed. An NFS server may wish to keep users’ files in separate areas, and thus it would create individual export directories for each client. This can also have a bearing on file permissions as discussed below, insofar as users may be completely denied access to other users’ directories, or may be allowed read permissions only. This can be extended down to individual files within the directories, if wished.
In this instance, the entries in the directories box might look more like this:
Directories to Export
/home/julia/Shared/paul
/home/julia/Shared/tom
The Hosts box refers to all the other computers on the network, known as hosts. The * denotes that all hosts in the network may share the files with the permissions given in the options box, but it is also possible to add individual hosts, and change the permissions granted to them.
For example: the user julia on host defiant, may wish to give full read and write permissions to the user paul on host enterprise, so that paul is able to change and/or delete files in the home/julia/Shared directory, but only wishes to grant read permissions to the user tom on host voyager. In this case, she would create two separate entries in the hosts file, one for paul and one for tom. User paul is granted read and write permissions (rw), but User tom is only granted read permissions (r-)
When adding a host you can use the hostname, (voyager and enterprise in this example), group, or IP Address, which in our subnet could be 192.168.5.41 for voyager and 192.168.5.42 for enterprise, (Again, Tutorial 3 contains info on IP Addressing).
The example and table shown above assume that the hostname on julia’s computer has been manually changed from the initially assigned, but rather bland and unmemorable linux-k528, to defiant, in keeping with the Star Trek™ theme. Choosing familiar and easily memorable hostnames is quite useful in a small, private network, but has less relevance in a larger-scale network. Naturally, one may pick one’s own memorable set of computer hostnames!
The other options set parameters for shares such as root_squash which means that users who have admin rights on their own computers - they can login as root as we are doing here -, do not inherit root permissions on any other machine in the network. (Conversely, no_root_squash does allow this, but it is normally not a wise or secure option to allow). Sync refers to synchronisation of files and is generally permitted.
Click Finish and you return to the main YAST window.
As you have probably gathered by now, this process needs to be repeated on all other hosts in the network.
NFS Client:
Once the networked computers have all been configured to be NFS Servers, they must all be configured to be NFS Clients. Still within YAST, go to Network Services, and then NFS Client. Click on Add in the NFS Client Configuration window:
In the dalog box that comes up, we need to add all the other computers in our network as NFS Servers. In the example above, the host enterprise has been added. The Remote File System refers to the file system on the host enterprise which has the user, paul. User paul has created individual directories for each user on the network in his Shared directory in exactly the same way as julia has done on the host machine defiant, (which is the computer we are working on in this example). The local Mount Point is the directory (on defiant), that the files will be exported to. In this case, it is the directory that was created earlier to share files with paul on the host enterprise. We can see therefore that directories have been created on every computer for each user on the network, and that our task is to match up all computers and users as servers and clients.
This next example shows the configuration of enterprise as the NFS Client with voyager as the NFS Server.
Network Information Service (NIS):
Just to muddy the waters still further, when we say that Linux is a multi-user system, we mean that each computer can have several different users, and although in this guide we have only added one user per machine, in practice it is likely that all the machines in the network will have several users each, all of whom need to be added to the network with identical uids, and possibly have individual shared directories created for them on each computer. Before we start reaching for the headache tablets, it may come as a relief to know that this is where the afore-mentioned NIS (Network Information Service) comes into play.
One could also use LDAP (Lightweight Directory Access Protocol), but this is most suited to enterprise level networks. In fact, the LDAP Server service is only included in enterprise level operating systems such as SLES (SuSE Linux Enterprise Server), Redhat AS, and CentOS. SuSE 10 does offer the option of setting up an LDAP Client, however.
NIS is an automated system which ensures that the uids on the client and server match up. It is a simple, cheap, (it is shipped free with virtually all Linux/Unix systems), and easy to set up system, which was set up to work with NFS, hence it’s popularity.
NIS uses a real client/server system where each network has one master server and possibly, if it is big enough, some slave servers as well. All other computers within the network are NIS clients, and use the NIS server for authentication and synchronisation of userIDs, groupIDs, network passwords etc.
To set up an NIS server, choose the largest machine in the network, and go to Yast, Network Services, NIS Server. Select Create Master Server. Choose a domain name for the NIS domain that you are creating. This needs to be different from the TCP/IP domain name created earlier to avoid confusion and potential security compromises. As our TCP/IP domain is test-lan.local, we will use test-nis.local for our NIS domain. As there is only one server in our network, make sure Active Slave NIS Server exists is unchecked, and click next. One may wish to allow users to change passwords, and make changes to their login shell. Select which maps (files) to export from the server to the clients, and click next. Add your netmask and network details into the next screen.
The first entry must exist to allow connections from the local host, but you can delete the entry 0.0.0.0 0.0.0.0 which allows connections from all hosts, and is thus a potential security risk. Add the details of your own network, which in our case is 255.255.255.0 and 192.168.5.0 and click Finish.
All other computers in our network need to be configured as NIS Clients. Go to Yast, Network Services, NIS Client. Check Use NIS, Static setup, Fill in the NIS domain (test-nis.local), and the IP Address of the NIS Server. Uncheck Broadcast, as this is a security risk, and click Finish.
Windows and Linux Networking:
Network interoperability between Linux and Windows is provided by the Samba software suite. Linux systems can run as both Samba Server and Samba Client, (much like NFS Servers and Clients), except that files and resources such as printers can be shared between Linux and Windows systems.
Linux supports the Windows SMB (Server Message Block), protocol which underlies most Windows networking mechanisms, but has now been subsumed into Microsoft’s Common Internet File Services (CIFS). SMB is a NetBIOS (Network Basic Input Output System), implementation that runs over TCP/IP, (NBT),which replaced NetBEUI (NetBIOS Extended User Interface), as networks became larger, and required services such as routing, which NetBEUI could not provide. Samba was created as NetBIOS for Unix in 1991, and was renamed Samba in 1994.
Configuration:
Samba Servers and Clients can be configured by going to Network Services and clicking on Samba Server and Windows Domain Membership (Samba Client) respectively. We will begin with the Samba Client (or Windows Domain Membership as it now seems to be called).
We are joining the Windows workgroup (test-lan), that we created in Task 1 when we set up our Windows Network. As this is a workgroup and not a domain, we cannot use SMB information for Linux Authentication so leave this unchecked. Click Finish and our Linux computer is now a member of the windows workgroup. Browsing resources on the Windows network is most easily done by using the browser Konqueror.
The screenshot above shows the Samba shares in the test-lan network, with SuSE10 (our Linux computer) and Ws001 one of our Windows computers in the workgroup.
The Samba Server can be set up by going to Yast, Network Services, Samba Server. First choose your Windows workgroup or domain (in our case test-lan). Specify whether or not it is a Primary Domain Controller (PDC) - this is only applicable to domains, and as our Windows network is a workgroup and not a domain, this does not apply. Choose whether the Samba service will start automatically at boot or manually, Add any directories that you wish to share with the Windows computers into the Shares tab, and pick a NetBIOS hostname, which is the name that Windows will see. As can be seen in the screenshot, our NetBios hostname is Suse10.
Client/Server and Peer to Peer Models:
The terms client/server and peer to peer have been used periodically in the preceding guides, and it is probably useful at this point to clarify exactly what we mean by these terms. Essentially, a client/server network is a centralised network which has a one to many relationship, and a peer to peer network is a distributed network with a many to many relationship.
A centralised network retains most, if not all, of the control at the centre, which is the server. The clients are all the computers that it serves. What does it serve? Well, at one end of the spectrum, all user information, files, programs, applications, services and so on are held on the server, and are available to the client machines when a user supplies credentials by logging in to the system. These terminals are known as thin clients, with little more than operating system, monitor, keyboard, mouse, and network cable or wireless connectivity. At the other end of the scale, clients can be relatively autonomous workstations with their own HDDs (Hard Disk Drives) CPUs etc, and a full range of applications and services. They can function perfectly well as stand alone computers, but use a server to provide them with Network services and Internet connectivity. There are of course, several variants in between.
A distributed network on the other hand, connects computers of equal standing together, for the purposes of file and print sharing, usually. All these computers may also be connected to a router to provide Internet connectivity. In a peer to peer relationship, every computer acts as both client and server to each other.
Many Windows home networks have peer to peer relationships as described above. At Enterprise level however, both Windows and Linux networks generally run client/server models using domains and Primary Domain Controllers (PDCs), as discussed in the section on Samba.
The NFS file sharing system described in this guide, is technically a peer to peer system, but in fact, actually uses a one to many system, masquerading as a many to many. This is because in a Linux network, NFS works on the client/server model, but each workstation may also be client and server. NIS however, has only one NIS server per domain, with all workstations being NIS clients.
Conclusion:
That just about rounds up our set of step by step guides to Windows and Linux installation and networking. I hope that you have found these guides useful and informative; and will come back for the final instalment in the series, (Tutorial 4), when we look at the wider issues of computer networking, and discuss the relative merits of both Linux and Windows Operating Systems for this task.
