What is the networks file in windows. What should be in the networks file

Good time, dear readers. I am posting the second part. The current section focuses on network implementation in linux(how to set up a network in Linux, how to diagnose a network in Linux and maintain the network subsystem in Linux).

Configuring TCP/IP on Linux for Ethernet Networking

To work with TCP / IP network protocols in Linux, it is enough to have only loopback interface, but if you need to combine hosts with each other, of course, you need a network interface, data transmission channels (for example, twisted pair), possibly some kind of network equipment. Also, it is necessary to have installed (, etc.), usually supplied in . It also needs to have a network (for example /etc/hosts) and network support.

Network settings

Let's start understanding Linux networking mechanisms by manually configuring the network, that is, from the case when IP address network interface static. So, when setting up a network, you need to take into account and configure the following parameters:

IP address- as already mentioned in the first part of the article - this is a unique address of the machine, in the format of four decimal numbers separated by dots. Usually, when working in local network, selected from private ranges, for example: 192.168.0.1

Subnet mask- also, 4 decimal numbers that determine which part of the address refers to the network / subnet address, and which part to the host address. The subnet mask is a number that is added (in binary form) with an IP address to find out which subnet the address belongs to. For example, the address 192.168.0.2 with the mask 255.255.255.0 belongs to the subnet 192.168.0.

Subnet address- determined by the subnet mask. At the same time, there are no subnets for loopback interfaces.

Broadcast address- the address used to send broadcast packets that will be received by all hosts on the subnet. Usually, it is equal to the subnet address with a host value of 255, that is, for subnet 192.168.0, the broadcast will be 192.168.0.255, similarly, for subnet 192.168, the broadcast will be 192.168.255.255. There is no broadcast address for loopback interfaces.

Gateway IP address is the address of the machine that is the default gateway for communication with the outside world. There can be multiple gateways if the computer is connected to multiple networks at the same time. The gateway address is not used on isolated networks (not connected to the WAN), because these networks have nowhere to send packets outside the network, the same applies to loopback interfaces.

Name server IP address (DNS server)- address of the server that converts hostnames to IP addresses. Usually provided by the ISP.

Linux network settings files (config files)

To understand the networking in Linux, I would definitely advise you to read the article "". In general, all Linux work is based on, which is born when the OS boots and produces its descendants, which in turn do all the necessary work, whether it's running bash or a daemon. Yes, and the entire Linux boot is based on, which spell out the entire sequence of launching small utilities with various parameters that are sequentially started / stopped when the system starts / stops. The Linux network subsystem starts in the same way.

Each Linux distribution has a slightly different network initialization mechanism, but the overall picture, I think, after reading will be clear. If you look at the start scripts of the network subsystem of some Linux distribution, then how to set up the network configuration using configuration files will become more or less clear, for example, in Debian (we will take this distribution as a basis), the script is responsible for initializing the network /etc/init.d/networking by viewing which:

Net-server:~#cat /etc/init.d/networking #!/bin/sh -e ### BEGIN INIT INFO # Provides: networking # Required-Start: mountkernfs $local_fs # Required-Stop: $local_fs # Should -Start: ifupdown # Should-Stop: ifupdown # Default-Start: S # Default-Stop: 0 6 # Short-Description: Raise network interfaces. ### END INIT INFO PATH="/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin" [ -x /sbin/ifup ] || exit 0 . /lib/lsb/init-functions process_options() ( [ -e /etc/network/options ] || return 0 log_warning_msg "/etc/network/options still exists and it will be IGNORED! Read README.Debian of netbase." ) check_network_file_systems() ( [ -e /proc/mounts ] || return 0 if [ -e /etc/iscsi/iscsi.initramfs ]; then log_warning_msg "not deconfiguring network interfaces: iSCSI root is mounted." exit 0 fi exec 9<&0 < /proc/mounts while read DEV MTPT FSTYPE REST; do case $DEV in /dev/nbd*|/dev/nd*|/dev/etherd/e*) log_warning_msg "not deconfiguring network interfaces: network devices still mounted." exit 0 ;; esac case $FSTYPE in nfs|nfs4|smbfs|ncp|ncpfs|cifs|coda|ocfs2|gfs|pvfs|pvfs2|fuse.httpfs|fuse.curlftpfs) log_warning_msg "not deconfiguring network interfaces: network file systems still mounted." exit 0 ;; esac done exec 0<&9 9<&- } check_network_swap() { [ -e /proc/swaps ] || return 0 exec 9<&0 < /proc/swaps while read DEV MTPT FSTYPE REST; do case $DEV in /dev/nbd*|/dev/nd*|/dev/etherd/e*) log_warning_msg "not deconfiguring network interfaces: network swap still mounted." exit 0 ;; esac done exec 0<&9 9<&- } case "$1" in start) process_options log_action_begin_msg "Configuring network interfaces" if ifup -a; then log_action_end_msg $? else log_action_end_msg $? fi ;; stop) check_network_file_systems check_network_swap log_action_begin_msg "Deconfiguring network interfaces" if ifdown -a --exclude=lo; then log_action_end_msg $? else log_action_end_msg $? fi ;; force-reload|restart) process_options log_warning_msg "Running $0 $1 is deprecated because it may not enable again some interfaces" log_action_begin_msg "Reconfiguring network interfaces" ifdown -a --exclude=lo || true if ifup -a --exclude=lo; then log_action_end_msg $? else log_action_end_msg $? fi ;; *) echo "Usage: /etc/init.d/networking {start|stop}" exit 1 ;; esac exit 0

you can find several functions that check for mounted network file systems ( check_network_file_systems(), check_network_swap()), as well as checking the existence of some yet incomprehensible config /etc/network/options ( function process_options()), and at the very bottom, by the design case "$1" in and in accordance with the entered parameter (start/stop/force-reload|restart or any other) performs certain actions. Of these very certain actions", the example of the start argument shows that the function is started first process_options, then the phrase is sent to the log Configuring network interfaces, and run the command ifup -a. If you look at man ifup , you can see that this command reads the config from the file /etc/network/interfaces and according to the key -a starts all interfaces that have the parameter auto.

The ifup and ifdown commands may be used to configure (or, respectively, deconfigure) network interfaces based on interface definitions in the file /etc/network/interfaces.

-a, --all
If given to ifup, affect all interfaces marked auto. Interfaces are brought up in the order in which they are defined in /etc/network/interfaces. If given to ifdown, affect all defined interfaces. Interfaces are brought down in the order in which they are currently listed in the state file. Only interfaces defined in /etc/network/interfaces will be brought down.

ip-server:~# cat /etc/network/interfaces # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo iface lo inet loopback # The primary network interface allow-hotplug eth0 iface eth0 inet dhcp allow-hotplug eth2 iface eth2 inet static address 192.168.1.1 netmask 255.255.255.0 gateway 192.168.1.254 broadcast 192.168.1.255

In this config line allow-hotplug And auto are synonyms and interfaces will be brought up on command ifup -a. That, in fact, is the whole chain of operation of the network subsystem. Similarly, in other distributions: in RedHat and SUSE, the network is started by a script /etc/init.d/network. Having examined it, you can similarly find where the network configuration lies.

/etc/hosts

This file contains a list IP addresses And hostnames corresponding to them (addresses).The file format is no different from the master file:

ip-server:~# cat /etc/hosts # ip host.in.domain host 127.0.0.1 localhost 127.0.1.1 ip-server.domain.local ip-server 192.168.1.1 ip-server.domain.local ip-server

Historically, this file has been used in place of the DNS service. Currently, the file can also be used instead of the DNS service, but only on the condition that the number of machines on your network is measured in units, and not in tens or hundreds, because in this case, you will have to control the correctness of this file on each machine.

/etc/hostname

This file contains NetBIOS hostname:

Ip-server:~# cat /etc/hostname ip-server

This file stores the names and addresses of local and other networks. Example:

Ip-server:~# cat /etc/networks default 0.0.0.0 loopback 127.0.0.0 link-local 169.254.0.0 home-network 192.168.1.0

When using this file, networks can be managed by name. For example, add a route not route add 192.168.1.12 , A route add.

/etc/nsswitch.conf

The file defines hostname lookup order/networks, the following lines are responsible for this setting:

For hosts: hosts: files dns For networks: networks: files

Parameter files specifies to use the specified files (/etc/hosts And /etc/networks respectively), parameter dns specifies to use the service dns.

/etc/host.conf

The file specifies name resolution options for the resolver

Ip-server:~# cat /etc/host.conf multi on

This file tells the resolv library to return all valid host addresses found in the /etc/hosts file, not just the first one.

/etc/resolv.conf

This file defines the parameters of the network name to IP address translation mechanism. In plain language defines DNS settings. Example:

Ip-server:~# cat /etc/resolv.conf nameserver 10.0.0.4 nameserver 10.0.0.1 search domain.local

First 2 lines indicate DNS servers. The third line specifies the search domains. If, when resolving a name, the name is not a FQDN name, then this domain is substituted as an "end". For example, when executing the ping host command, the pinged address is converted to host.domain.local. Other parameters can be read in man resolv.conf . Very often, Linux uses the dynamic generation of this file, using the so-called. programs /sbin/resolvconf. This program is an intermediary between services that dynamically provide name servers (for example, DHCP client) and services using name server data. To use a dynamically generated file /etc/resolv.conf, you need to make this file a symbolic link to /etc/resolvconf/run/resolv.conf. In some distributions, the path may be different, this will definitely be written in man resolvconf.

Network configuration

Having familiarized yourself with the main configuration files, you can look at the . The command has already been mentioned above. ifup, ifdown, but these tools are not quite universal, for example, in RH distributions, these commands are not available by default. In addition, new distributions have a new high-level network management tool - , which belongs to the iproute package. To him (the iproute package) I will dedicate . And in the current post I will not consider it. The commands described below belong to .

So, in order to be sure that the command will work in any Linux distribution, you need to use two basic old-fashioned commands. This is , and arp. First team (responsible for setting up network interfaces(ip, mask, gateway), second () - routing setup, third (arp) - arp table management. I would like to note that the execution of these commands without disabling the standard SystemV startup script of the network subsystem will make changes only until the first reboot / restart of the network service, because. if you think about it with your brains, you can understand that the script /etc/init.d/networking at the next start, it will reread the above configs and apply the old settings. Accordingly, the way out for permanently setting the settings is either the ifconfig command with the appropriate parameters - enter into, or manually correct the corresponding network interface configs.

Similarly, if the command ifconfig with missing options(for example, only the IP address), then the rest are completed automatically (for example, the broadcast address is added by default with a host address ending in 255 and the default subnet mask is 255.255.255.0).

Routing for available interfaces in modern kernels is always raised automatically by the kernel. Or rather, direct routes to the network according to the IP settings and the subnet into which the raised interface looks are formed automatically by the kernel. The field gateway (gateway) for such entries shows the address of the output interface or *. In older versions of the kernel (the number of the kernel from which the routes began to rise automatically - I won’t tell you), it was necessary to add the route manually.

If there is a need to organize routes, then you need to use . You can add and remove routes with this command, but again, this will only help until you restart /etc/init.d/networking (or another networking script in your distribution). In order for routes to be added automatically, it is necessary, just like with the ifconfig command, to add commands for adding routes to rc.local, or to correct the corresponding network interface configs by hand (for example, in Deb - /etc/network/options).

By what rules routes to networks are formed, I'm in

Linux Network Diagnostics

There are a large number of network diagnostic tools in Linux, often very similar to those from Microsoft. I will consider 3 main network diagnostic utilities, without which it will be problematic to identify problems.

I think that this utility is familiar to almost everyone. The job of this utility is to sending so-called ICMP packets remote server, which will be specified in the command parameters, the server returns the sent commands, and pingcounting time required for the sent packet to reach the server and return. For example:

# ping ya.ru PING ya.ru (87.250.251.3) 56(84) bytes of data. 64 bytes from www.yandex.ru (87.250.251.3): icmp_seq=1 ttl=57 time=42.7 ms from www.yandex.ru (87.250.251.3): icmp_seq=3 ttl=57 time=42.5 ms 64 bytes from www.yandex.ru (87.250.251.3): icmp_seq=4 ttl=57 time=42.5 ms 64 bytes from www .yandex.ru (87.250.251.3): icmp_seq=5 ttl=57 time=41.9 ms ^C --- ya.ru ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4012ms rtt min/ avg/max/mdev = 41.922/42.588/43.255/0.500ms

As can be seen from the above example, ping gives us a lot of useful information. First of all, we found out that we can establish a connection with the host ya.ru(sometimes they say that "ya.ru host is available to us"). Secondly, we see that DNS is working correctly, because the "pinged" name was correctly converted to an IP address (PING ya.ru (87.250.251.3)). Further, in field icmp_seq= set numbering of sent packets. Each sent packet is sequentially assigned a number, and if there are “gaps” in this numbering, then this will tell us that the connection with the “pinged” is unstable, and it may also mean that the server to which the packets are sent is overloaded. By value time= we see, how long did the package travel to 87.250.251.3 and back. You can stop the ping utility by pressing Ctrl+C.

Also, ping utility interesting in that it can allow you to see exactly where the problems arose. Let's say ping utility displays a message network not reachable or other similar message. This most likely indicates an incorrect configuration of your system. In this case, you can send packets to the ISP's IP address to find out where the problem occurs (between the local PC or "beyond"). If you are connected to the Internet through a router, then you can send packets to its IP. Accordingly, if the problem appears already at this stage, this indicates an incorrect configuration of the local system, or cable damage, if the router responds and the provider's server does not, then the problem is in the provider's communication channel, etc. Finally, if the conversion of the name to IP fails, then you can check the connection over IP, if the answers come correctly, then you can guess that the problem is in DNS.

It should be noted that this utility is not always a reliable diagnostic tool. The remote server can block responses to ICMP requests.

traceroute

In simple terms, the team is called route trace. As you can understand from the name, this utility will show which route the packets went to the host. traceroute utility somewhat similar to ping, but displays more interesting information. Example:

# traceroute ya.ru traceroute to ya.ru (213.180.204.3), 30 hops max, 60 byte packets .kubtelecom.ru (213.132.64.65) 2.761 ms 5.787 ms 5.777 ms 3 lgw.kubtelecom.ru (213.132.75.54) 5.713 ms 5.701 ms 5.636 ms 4 (194.186.6.177) 81.430ms 81.581 ms 81.687 ms 5 cat26.Moscow.gldn.net (194.186.10.118) 47.789 ms 47.888 ms 48.011 ms 6 213.33.201.230 (213.33.201.230) 43.322 ms 41.783 ms 41. 106 ms 7 carmine-red-vlan602.yandex.net (87.250. 242.206) 41.199 ms 42.578 ms 42.610 ms 8 www.yandex.ru (213.180.204.3) 43.185 ms 42.126 ms 42.679 ms

As you can see, you can trace the route from the router of the provider 243-083-free.kubtelecom.ru (213.132.83.243) (South of Russia) to the final host at www.yandex.ru (213.180.204.3) in Moscow.

dig

This utility sends queries to DNS servers and returns information about the specified domain. Example:

# dig @ns.kuban.ru roboti.ru ;<<>> DiG 9.3.6-P1<<>> @ns.kuban.ru roboti.ru ; (1 server found) ;; global options: print cmd ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64412 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;roboti.ru. IN A ;; ANSWER SECTION: roboti.ru. 448 IN A 72.52.4.90 ;; AUTHORITY SECTION: roboti.ru. 345448 IN NS ns1.sedoparking.com. roboti.ru. 345448 IN NS ns2.sedoparking.com. ;; Query time: 102 msec ;; SERVER: 62.183.1.244#53(62.183.1.244) ;; WHEN: Thu Feb 17 19:44:59 2011 ;; MSG SIZE rcvd: 94

dig command sent a request DNS server - ns.kuban.ru (@ns.kuban.ru- this parameter is optional, in this case the source of information about DNS will be taken from the server from your system settings) about the domain name roboti.ru. As a result, I received a response, in which we can see in the section ANSWER SECTION information about the IP addresses of the domain, in the section AUTHORITY SECTION information about the so-called. authoritative DNS servers. The third line from the bottom tells us which server provided the response.

Other Diagnostic Utilities

ping, dig and other diagnostic utilities with parameters can be found in the post.

Connecting a new network card

Connecting and launching a new network card comes down to a few steps:

1. Physical connection of the card

3. View the output for the system to detect a new network card:

Let's see the output BEFORE connecting a new card:

Server:~# dmesg | grep eth [ 4.720550] e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection [ 5.130191] e1000: eth1: e1000_probe: Intel(R) PRO/1000 Network Connection [ 15.285527] e1000: eth2: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX [ 15.681056] e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX

the output shows that the system has 2 network cards eth1 and eth2. We connect the third and look at the output:

Server:~# dmesg | grep eth [ 4.720513] e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection [ 5.132029] e1000: eth1: e1000_probe: Intel(R) PRO/1000 Network Connection [ 5.534684] e1000: eth2: e1000_probe: Intel(R ) PRO/1000 Network Connection [ 39.274875] udev: renamed network interface eth2 to eth3 [ 39.287661] udev: renamed network interface eth1_rename_ren to eth2 [ 45.670744] e1000: eth2: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX [ 46.237232] e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX [ 96.977468] e1000: eth3: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX

IN dmesg we see that a new network card has appeared - eth3, which is actually eth2, but has been renamed by the udev device manager to eth3, and eth2 is actually a renamed eth1 (we will talk about udev in a separate post). The appearance of our new network in dmesg tells us that the network card supported core and correct decided. The only thing left is to set up a new interface in /etc/network/interfaces(Debian) because the given map was not initialized by the start script /etc/init.d/network. ifconfig sees this card:

Server:~# ifconfig eth3 eth3 Link encap:Ethernet HWaddr 08:00:27:5f:34:ad inet6 addr: fe80::a00:27ff:fe5f:34ad/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric: 1 RX packets:311847 errors:0 dropped:0 overruns:0 frame:0 TX packets:126 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:104670651 (99.8 MiB) TX bytes: 16184 (15.8 KiB)

but besides - does not configure. How to configure a network card was discussed above.

Summary

I think that's all for today. When I started writing this article, I thought that I would fit into one post, but it turned out to be huge. Therefore, it was decided to break the article into two. In total, I tried to state, not a step-by-step how to configure the network, but to state the principle and explain the understanding of how the network starts and works in Linux. I really hope I succeeded. I will be glad to your comments and additions. Over time, I will supplement the article.

Once you have subnetted your network, you should prepare for a simple address-by-name lookup using the /etc/hosts file. If you are not going to use DNS or NIS for this, you must put all hosts in host file.

Even if you want to use DNS or NIS, you can have some subset of names in /etc/hosts as well. For example, if you want to have some kind of name lookup even when network interfaces are not running, such as at boot time. This is not only a matter of convenience, but also allows you to use symbolic hostnames in rc scripts. Thus, when changing IP addresses, you will only have to copy the updated hosts file to all machines instead of editing a lot of rc files. Typically you will put all local names and addresses in hosts by adding them to any gateway and NIS server if used.

Also, when checking, you should make sure that the nameserver only uses information from the hosts file. The DNS or NIS software may have sample files that may give strange results when used. To force all applications to exclusively use /etc/hosts when looking up a host's IP address, you must edit the /etc/host.conf file. Comment out all lines starting with the keyword order and paste the line:

order hosts

The nameserver library configuration will be described in detail in Chapter 6.

The hosts file contains one entry per line, consisting of an IP address, a hostname, and an optional list of aliases. The fields are separated by spaces or tabs, the address field must start in the first column. Anything after the # symbol is treated as a comment and ignored.

The hostname can be fully qualified or relative to the local domain. For vale, you would enter the fully qualified name, vale.vbrew.com , into hosts , as well as vale itself, so that both the official name and the shorter local name are known.

An example hosts file for Virtual Brewery is given below. Two special names, vlager-if1 and vlager-if2 , specify addresses for both interfaces used on vlager .

What is the practical use of the /etc/networks file? As far as I understand, it is possible to specify network names in this file. For example:

[email protected]:~# cat /etc/networks default 0.0.0.0 loopback 127.0.0.0 link-local 169.254.0.0 google-dns 8.8.4.4 [email protected]:~#

However, if I try to use this network name, for example in the ip utility, it doesn't work:

[email protected]:~# ip route add google-dns via 104.236.63.1 dev eth0 Error: an inet prefix is expected rather than "google-dns". [email protected]:~# ip route add 8.8.4.4 via 104.236.64.1 dev eth0 [email protected]:~#

What is the practical use of the /etc/networks file?

2 Solutions collect form web for “practical usage of /etc/networks file”

As written in the man page, the /etc/networks file should describe symbolic names for networks. With a network, this means a network address with a trailing .0 at the end. Only simple Class A, B, or C networks are supported.

In your example, the google-dns entry is wrong. It's not network A, B, or C. It's an ip-address-hostname relationship, so it belongs to /etc/hosts . In fact the default entry doesn't match either.

Let's say you have an IP address of 192.168.1.5 from your corporate network. An entry in /etc/network could be:

Corpname 192.168.1.0

When using utilities such as route or netstat , these networks are translated (unless you suppress permission with the -n flag). The routing table might look like this:

Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default 192.168.1.1 0.0.0.0 UG 0 0 0 eth0 corpname * 255.255.255.0 U 0 0 0 eth0

The ip command never uses the hostname for input, so your example hardly matters. Also you put the hostname in /etc/networks , not the networkname!

Entries in /etc/networks are used by tools that attempt to convert numbers to names, such as the (obsolete) route command. Without a suitable entry, it shows:

# route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default 192.168.1.254 0.0.0.0 UG 0 0 0 eth0 192.168.0.0 * 255.255.254.0 U 0 0 0 eth0

If we now add the line mylocalnet 192.168.0.0 to /etc/networks:

# route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default 192.168.1.254 0.0.0.0 UG 0 0 0 eth0 mylocalnet * 255.255.254.0 U 0 0 0 eth0

In practice, this is never used.

Go!

The Network File Server (NFS) protocol is an open standard for providing a user with remote access to file systems. Based on it, centralized file systems make it easier to perform daily tasks such as backups or virus checks, and concatenated disk partitions are easier to maintain than many small and distributed ones.

In addition to providing centralized storage, NFS has proven to be very useful for other applications, including diskless and thin clients, network clustering, and collaborative middleware.

A better understanding of both the protocol itself and the details of its implementation will make it easier to deal with practical problems. This article is devoted to NFS and consists of two logical parts: first, the protocol itself and the goals set during its development are described, and then the implementation of NFS in Solaris and UNIX.

WHERE IT ALL STARTED...

The NFS protocol was developed by Sun Microsystems and appeared on the Internet in 1989 as RFC 1094 under the following title: Network File System Protocol Specification (NFS). It is interesting to note that Novell's strategy at the time was to further improve file services. Until recently, while the open source movement was still in full swing, Sun did not want to reveal the secrets of its networking solutions, but even then the company understood the importance of interoperability with other systems.

RFC 1094 contained two original specifications. At the time of its publication, Sun was developing the next, third version of the specification, which is set out in RFC 1813 "NFS Protocol Specification, Version 3" (NFS Version 3 Protocol Specification). Version 4 of this protocol is defined in RFC 3010 NFS Protocol Specification Version 4 (NFS Version 4 Protocol).

NFS is widely used on all types of UNIX hosts, Microsoft and Novell networks, and IBM solutions such as AS400 and OS/390. Unknown outside the network realm, NFS is arguably the most widely used platform-independent network file system.

UNIX WAS THE GENERATOR

Although NFS is a platform-independent system, UNIX is its ancestor. In other words, the hierarchical architecture and methods of accessing files, including the structure of the file system, the ways in which users and groups are identified, and how files are handled, are all very similar to the UNIX file system. For example, the NFS file system, being identical in structure to file system UNIX is mounted directly on it. When working with NFS on other operating systems, user identities and file permissions are mapped.

NFS

The NFS system is designed to be used in a client-server architecture. The client accesses the file system exported by the NFS server through a mount point on the client. Such access is usually transparent to the client application.

Unlike many client/server systems, NFS uses Remote Procedure Calls (RPC) to exchange information. Typically, the client establishes a connection to a known port and then, in accordance with the protocol, sends a request to perform a certain action. In the case of a remote procedure call, the client creates a procedure call and then sends it to the server for execution. A detailed description of NFS will be presented below.

As an example, suppose a client has mounted the usr2 directory on the local root filesystem:

/root/usr2/ -> remote:/root/usr/

If a client application needs the resources of this directory, it simply sends a request to the operating system for it and for the file name, which provides access through the NFS client. For example, consider the simple UNIX cd command, which "knows nothing" about network protocols. Team

Cd /root/usr2/

will place the working directory on the remote file system without "even knowing" (the user doesn't need to know either) that the file system is remote.

Upon receiving the request, the NFS server will check whether the given user has the right to perform the requested action and, if the answer is positive, will perform it.

LET'S GET TO KNOW BETTER

From the client's point of view, the process of mounting a remote file system locally using NFS consists of several steps. As already mentioned, the NFS client will submit a remote procedure call to execute it on the server. Note that in UNIX the client is a single program (the mount command), while the server is actually implemented as several programs with the following minimal set: port mapper service (port mapper), mount daemon (mount daemon) and NFS server .

The client's mount command first communicates with the server's port translation service, which listens for requests on port 111. Most implementations of the client's mount command support multiple versions of NFS, making it more likely that the client and server will find a common protocol version. The search is carried out starting from the oldest version, so when a common one is found, it will automatically become the newest version supported by the client and server.

(This material is focused on the third version of NFS, since it is the most common at the moment. The fourth version is not yet supported by most implementations.)

The server port translation service responds to requests according to the supported protocol and the port on which the mount daemon is running. The client's mount program first establishes a connection to the server's mount daemon and then sends the mount command to it via RPC. If this procedure is successful, then the client application connects to the NFS server (port 2049) and, using one of the 20 remote procedures defined in RFC 1813 and listed in Table 1, accesses the remote file system.

The meaning of most commands is intuitive and does not cause any difficulties for system administrators. The following listing, produced using tcdump, illustrates the read command used by the UNIX cat command to read a file named test-file:

10:30:16.012010 eth0 > 192.168.1.254. 3476097947 > 192.168.1.252.2049: 144 lookup fh 32.0/ 224145 "test-file" 10:30:16.012010 eth0 > 192.168.1.254. 3476097947 > 192.168.1.252.2049: 144 lookup fh 32.0/ 224145 "test-file" 10:30:16.012729 eth0 192.168.1.254.3476097947: reply ok 128 lookup fh 32.0/22 4307 (DF) 10:30: 16.012729 eth0 192.168.1.254.3476097947: reply ok 128 lookup fh 32.0/224307 (DF) 10:30:16.013124 eth0 > 192.168.1.254. 3492875163 > 192.168.1.252.2049: 140 read fh 32.0/ 224307 4096 bytes @ 0 10:30:16.013124 eth0 > 192.168.1.254. 3492875163 > 192.168.1.252.2049: 140 read fh 32.0/ 224307 4096 bytes @ 0 10:30:16.013650 eth0 192.168.1.254.3492875163: reply ok 108 read (DF) 10: 30:16.013650 eth0 192.168.1.254.3492875163 : reply ok 108 read (DF)

NFS has traditionally been implemented over UDP. However, some versions of NFS support TCP (TCP support is defined in the protocol specification). The main advantage of TCP is a more efficient retransmission mechanism in unreliable networks. (In the case of UDP, if an error occurs, then the complete RPC message, consisting of several UDP packets, is retransmitted. With TCP, only the corrupted fragment is retransmitted.)

ACCESS TO NFS

NFS implementations typically support four methods of granting access: via user/file attributes, at the share level, at the master node level, and as a combination of other access methods.

The first method is based on the built-in UNIX system file permissions for an individual user or group. To simplify maintenance, user and group identification should be consistent across all NFS clients and servers. Security must be carefully considered: NFS can inadvertently grant access to files that was not intended when they were created.

Shared resource access allows you to restrict rights to only certain actions, regardless of file ownership or UNIX privileges. For example, working with the NFS file system can be limited to read only. Most implementations of NFS allow you to further restrict access at the level of shared resources to specific users and/or groups. For example, the Human Resources group is allowed to view information and nothing more.

Master-level access allows you to mount a filesystem only on specific nodes, which is generally a good idea because filesystems can easily be created on any nodes that support NFS.

Combined access simply combines the above types (for example, share-level access with access granted to a specific user) or allows users to access NFS only from a specific host.

NFS PENGUIN STYLE

The Linux-related material presented here is based on a Red Hat 6.2 system with kernel version 2.4.9, which ships with version 0.1.6 of the nfs-utils package. Newer versions also exist: at the time of this writing, the most recent update to the nfs-utils package is 0.3.1. It can be downloaded at: .

The nfs-utils package contains the following executable files: exportfs, lockd, mountd, nfsd, nfsstat, nhfsstone, rquotad, showmount and statd.

Unfortunately, NFS support is sometimes confusing for Linux administrators, as the availability of a particular feature is directly dependent on the version numbers of both the kernel and the nfs-utils package. Fortunately, things are improving in this area now: the latest distribution kits include the latest versions of both. For previous releases, see Section 2.4 of the NFS-HOWTO for a complete list functionality systems available for each combination of kernel and nfs-utils package. The developers maintain the backward compatibility of the package with earlier versions, paying a lot of attention to security and fixing software bugs.

NFS support must be initiated at kernel compilation time. If necessary, the ability to work with NFS version 3 must also be added to the kernel.

For distributions that support linuxconf, it's easy to configure NFS services for both clients and servers. However, the quick way to set up NFS using linuxconf does not provide information about what files were created or edited, which is very important for the administrator to know in case of a system failure. The architecture of NFS on Linux is loosely coupled to the BSD version, so the necessary support files and programs are easy to find for administrators running BSD, Sun OS 2.5, or earlier versions of NFS.

The /etc/exports file, as in earlier versions of BSD, specifies the filesystems that NFS clients are allowed to access. In addition, it contains a number additional features related to management and security issues, providing the administrator with a tool for fine-tuning. This text file, consisting of entries, empty lines, or commented lines (comments start with #).

Let's say we want to give clients read-only access to the /home directory on the Lefty host. This would correspond to the following entry in /etc/exports:

/home (ro)

Here we need to tell the system which directories we are going to make available using the rpc.mountd mount daemon:

# exportfs -r exportfs: No hostname specified in /home (ro), type *(ro) to avoid warning #

When run, the exportfs command warns that /etc/exports does not restrict access to a particular node, and creates a corresponding entry in /var/lib/nfs/etab from /etc/exports telling you which resources can be viewed with cat:

# cat /var/lib/nfs/etab /home (ro,async,wdelay,hide,secure,root_squash, no_all_squash,subtree_check, secure_locks, mapping=identity,anonuid= -2,anongid=-2)

Other options listed in etab include the defaults used by NFS. Details will be described below. To grant access to the /home directory, the appropriate NFS services must be started:

# portmap # rpc.mountd # rpc.nfsd # rpc.statd # rpc.rquotad

At any time after the mount daemon (rpc.mountd) has started, you can inquire about the individual files available for output by viewing the contents of the /proc/fs/nfs/exports file:

# cat /proc/fs/nfs/exports # Version 1.0 # Path Client(Flags) # IPs /home 192.168.1.252(ro,root_squash,async, wdelay) # 192.168.1.252 #

The same can be viewed using the showmount command with the -e option:

# showmount -e Export list for lefty: /home (everyone) #

Going a bit ahead, the showmount command can also be used to determine all mounted filesystems, or in other words, to find out which hosts are NFS clients for the system running the showmount command. The showmount -a command will list all client mount points:

# showmount -a All mount points on lefty: 192.168.1.252:/home #

As noted above, most NFS implementations support various versions of this protocol. The Linux implementation allows you to limit the list of NFS versions that will run by specifying the -N option for the mount daemon. For example, to start NFS version 3, and only version 3, enter the following command:

# rpc.mountd -N 1 -N 2

Fastidious users may find it inconvenient that on Linux the NFS daemon (rpc.nfsd) is waiting for version 1 and version 2 packages, although this achieves the desired effect of not supporting the corresponding protocol. Let's hope that the developers of the next versions will make the necessary corrections and will be able to achieve greater consistency between the package components in relation to different versions of the protocol.

"SWIMMING WITH PENGUINS"

Access to the above-configured Lefty, Linux-based NFS exportable file system is dependent on the client operating system. Settings style for most operating systems UNIX families matches the style of either the original Sun OS and BSD systems, or the newer Solaris. Since this article focuses on both Linux and Solaris, let's look at the Solaris 2.6 client configuration from the point of view of establishing a connection to the Linux version of NFS we described above.

With features inherited from Solaris 2.6, it is easy to configure it to act as an NFS client. This requires only one command:

# mount -F nfs 192.168.1.254:/home /tmp/tmp2

Assuming the previous mount command succeeded, then the mount command with no options will output the following:

# mount / on /dev/dsk/c0t0d0s0 read/write/setuid/ largefiles on Mon Sep 3 10:17:56 2001 ... ... /tmp/tmp2 on 192.168.1.254:/home read/ write/remote on Mon Sep 3 23:19:25 2001

Let's analyze the tcpdump output on the Lefty host after the user has entered the ls /tmp/tmp2 command on the Sunny host:

# tcpdump host lefty and host sunny -s512 06:07:43.490583 sunny.2191983953 > lefty.mcwrite.n.nfs: 128 getattr fh Unknown/1 (DF) 06:07:43.490678 lefty.mcwrite.n.nfs > sunny. 2191983953: reply ok 112 getattr DIR 40755 ids 0/0 sz 0x000001000 (DF) 06:07:43.491397 sunny.2191983954 > lefty.mcwrite.n.nfs: 132 access fh Unknown/10001 (DF) 06:07:4 3.491463 lefty. mcwrite.n.nfs > sunny.2191983954: reply ok 120 access c0001 (DF) 06:07:43.492296 00 (DF) 06:07:43.492417 lefty.mcwrite.n.nfs > sunny.2191983955: reply ok 1000 readdirplus (DF)

We see that the Sunny node asks for a file descriptor (fh) for ls, to which the Lefty node sends OK in response and returns the directory structure. Sunny then checks the permission for the contents of the directory (132 access fh) and receives a permission response from Lefty. The Sunny node then reads the full contents of the directory using the readdirplus procedure. Remote procedure calls are described in RFC 1813 and are listed at the beginning of this article.

Although the sequence of commands for accessing remote file systems is very simple, a number of circumstances can cause the system to mount incorrectly. Before mounting a directory, the mount point must already exist, otherwise it must be created using the mkdir command. Usually the only cause of errors on the client side is the lack of a local mount directory. Most of the problems associated with NFS, however, owe their origin to a mismatch between the client and the server, or incorrect server configuration.

The easiest way to troubleshoot problems on a server is from the host where the server is running. However, when someone else administers the server instead of you, this is not always possible. Fast way make sure the appropriate server services are configured correctly - use the rpcinfo command with the -p option. From the Solaris Sunny host, you can determine which RPC processes are registered on the Linux host:

# rpcinfo -p 192.168.1.254 program vers proto port service 100000 2 tcp 111 rpcbind 100000 2 udp 111 rpcbind 100024 1 udp 692 status 100024 1 tcp 694 status 100005 3 udp 102 4 mountd /100005 3 tcp 1024 mountd 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100021 1 udp 1026 nlockmgr 100021 3 udp 1026 nlockmgr 100021 4 udp 1026 nlockmgr #

Note that version information is also provided here, which is quite useful when the system requires support for various NFS protocols. If any service is not running on the server, then this situation should be corrected. If the mount fails, the following rpcinfo -p command will tell you that the mountd service on the server is down:

# rpcinfo -p 192.168.1.254 program vers proto port service 100000 2 tcp 111 rpcbind ... ... 100021 4 udp 1026 nlockmgr #

The rpcinfo command is very useful for finding out if a particular remote process is active. The -p option is the most important of the switches. See the man page for all the features of rpcinfo.

Another useful tool is the nfsstat command. With its help, you can find out whether clients are actually accessing the exported file system, as well as display statistical information according to the protocol version.

Finally, another fairly useful tool for determining the causes of system failures is tcpdump:

# tcpdump host lefty and host sunny -s512 tcpdump: listening on eth0 06:29:51.773646 sunny.2191984020 > lefty.mcwrite.n.nfs: 140 lookup fh Unknown/1"test.c" (DF) 06:29:51.773819 lefty.mcwrite.n.nfs > sunny.2191984020: reply ok 116 lookup ERROR: No such file or directory (DF) 06:29:51.774593 sunny.2191984021 > lefty.mcwrite.n.nfs: 128 getattr fh Unknown/1 ( DF) 06:29:51.774670 lefty.mcwrite.n.nfs > sunny.2191984021: reply ok 112 getattr DIR 40755 ids 0/0 sz 0x000001000 (DF) 06:29:51.775289 sunny.2191984022 > lefty.mcwrite .n.nfs : 140 lookup fh Unknown/1"test.c" (DF) 06:29:51.775357 lefty.mcwrite.n.nfs > sunny.2191984022: reply ok 116 lookup ERROR: No such file or directory (DF) 06:29: 51.776029 sunny.2191984023 > lefty.mcwrite.n.nfs: 184 create fh Unknown/1 "test.c" (DF) 06:29:51.776169 lefty.mcwrite.n.nfs > sunny.2191984023: reply ok 120 create ERROR: Permission denied (DF)

The above listing, obtained after executing the touch test.c statement, shows the following sequence of actions: first, the touch command tries to access a file named test.c, then it looks for a directory with the same name, and after unsuccessful attempts, it tries to create the file test.c , which also fails.

If the filesystem is mounted, most of the common errors are related to normal UNIX permissions. Sun's use of uid or NIS+ avoids setting permissions globally on all filesystems. Some administrators practice "open" directories, where permissions to read them are given to "the whole world". However, this should be avoided for security reasons. Security concerns aside, this is still a bad practice because users rarely create data with the intention of making it readable by everyone.

Accesses by a privileged user (root) to NFS mounted file systems are treated differently. To avoid granting unrestricted access to a privileged user, requests from the privileged user are treated as if they were from the user "nobody". This powerful mechanism restricts privileged user access to globally readable and writable files.

NFS SERVER, SOLARIS VERSION

Configuring Solaris to act as an NFS server is as easy as with Linux. However, the commands and file locations are slightly different. When Solaris boots up, when boot level 3 is reached, NFS services are automatically started and all file systems are exported. To start these processes manually, enter the command:

#/usr/lib/nfs/mountd

To start the mount daemon and NFS server, type:

#/usr/lib/nfs/nfsd

Starting with version 2.6, Solaris no longer uses an export file to specify which file systems to export. The files are now exported using the share command. Suppose we want to allow remote hosts to mount /export/home. To do this, enter the following command:

Share -F nfs /export/home

Security measures

SECURITY IN LINUX

Some Linux-based NFS system services have an additional mechanism for restricting access through control lists or tables. At the internal level, this mechanism is implemented using the tcp_wrapper library, which uses two files to form access control lists: /etc/hosts.allow and /etc/hosts/deny. An exhaustive overview of the rules for working with tcp_wrapper is beyond the scope of this article, but the basic principle is the following: matching is done first with etc/hosts.allow, and then with /etc/hosts. deny. If the rule is not found, then the requested system service is not presented. To get around the last requirement and provide a very high level of security, you can add the following entry to the end of /etc/hosts.deny:

ALL: All

After that, /etc/hosts.allow can be used to set this or that mode of operation. For example, the file /etc/hosts. allow , which I used when writing this article, contained the following lines:

lockd:192.168.1.0/255.255.255.0 mountd:192.168.1.0/255.255.255.0 portmap:192.168.1.0/255.255.255.0 .168.1.0/255.255.255.0

This allows some kind of access to nodes before granting access at the application layer. IN Linux access at the application level, the /etc/exports file controls. It consists of entries in the following format:

Export directory (space) host|network(options)

An "exported directory" is a directory that the nfsd daemon is allowed to process a request for. "Host|Network" is the host or network that has access to the exported filesystem, and "options" determines what restrictions the nfsd daemon imposes on the use of this shared resource - read-only access or user id mapping .

The following example grants the entire mcwrite.net domain read-only access to /home/mcwrite.net:

/home/mcwrite.net *.mcwrite.net(ro)

More examples can be found in the exports man page.

NFS SECURITY IN SOLARIS

In Solaris, the ability to provide NFS access is similar to Linux, but in this case, restrictions are set using certain options in the share command with the -o switch. The following example shows how to enable read-only mounting of /export/mcwrite.net on any host in the mcwrite.net domain:

#share -F nfs -o ro=.mcwrite.net/ export/ mcwrite.net

The share_nfs man page details how to grant access using control lists on Solaris.

Internet resources

NFS and RPC were not without "holes". Generally speaking, NFS should not be used on the Internet. You can't "hole" firewalls by allowing access of any kind through NFS. All RPC and NFS patches should be closely monitored, and numerous sources of security information can help. The two most popular sources are Bugtraq and CERT:

The first can be viewed regularly in search of the necessary information or use a subscription to a periodic newsletter. The second one provides, perhaps, not so prompt, in comparison with others, information, but in a fairly complete volume and without a hint of sensationalism, characteristic of some sites dedicated to information security.

Sometimes networks and other Windows system errors can be related to problems in the Windows registry. Several programs may be using the networks file, but when those programs are removed or changed, sometimes orphaned (invalid) Windows registry entries are left behind.

Basically, this means that while the actual path to the file may have been changed, its incorrect former location is still recorded in the Windows registry. When Windows tries to look up this incorrect file reference (file locations on your PC), networks. In addition, malware infection may have corrupted the registry entries associated with Microsoft Windows. Thus, these corrupted Windows registry entries need to be repaired in order to fix the root of the problem.

Manually editing the Windows registry to remove invalid networks keys is not recommended unless you are PC service professional. Mistakes made while editing the registry can render your PC unusable and cause irreparable damage to your operating system. In fact, even a single comma in the wrong place can prevent your computer from booting up!

Because of this risk, we highly recommend using a trusted registry cleaner such as WinThruster (Developed by Microsoft Gold Certified Partner) to scan and repair any networks. Using a registry cleaner automates the process of finding invalid registry entries, missing file references (like the one causing your networks error), and broken links within the registry. Before each scan, an automatically created backup copy, which allows you to undo any changes with a single click and protects you from possible damage to your computer. The best part is that fixing registry errors can drastically improve system speed and performance.

Warning: If you are not experienced user PC, we do NOT recommend editing the Windows registry manually. Incorrect use of the Registry Editor can lead to serious problems and require you to reinstall Windows. We do not guarantee that problems resulting from misuse of Registry Editor can be resolved. You use the Registry Editor at your own risk.

Before manually restoring Windows registry, you need to back up by exporting the networks part of the registry (for example, Microsoft Windows):

Click on the button Begin.
Enter " command" V search bar... DO NOT PRESS YET ENTER!
Holding keys CTRL-Shift on the keyboard, press ENTER.
An access dialog will be displayed.
Click Yes.
The black box opens with a blinking cursor.
Enter " regedit" and press ENTER.
In the Registry Editor, select the networks-related key (eg. Microsoft Windows) you want to back up.
On the menu File select Export.
Listed Save to select the folder where you want to save the Microsoft Windows key backup.
In field File name enter a name for the backup file, such as "Microsoft Windows Backup".
Make sure the field Export range value selected Selected branch.
Click Save.
The file will be saved with .reg extension.
You now have a backup of your networks.

The next steps for manually editing the registry will not be covered in this article, as they are likely to damage your system. If you would like more information on editing the registry manually, please see the links below.