Etc folder is the folder that contains the following text files hosts, lmhosts.sam, networks, protocol, services this is the standard content of the etc folder for Windows XP and Windows 7.
It’s easy to find where the etc folder is located, click “Start” - “Computer” - “ Local disk C" - "Windows" - "System32" - "drivers" - "etc".
What files are in the etc folder
If you have lost the etc folder, you can download the etc folder for Windows 7 and for Windows 8.
Now I will describe how to restore the etc folder by downloading the archive of the etc folder and unzip it. Just copy etc, find where it should be and paste it. The etc folder for Windows 7 is no different from the etc folder for Windows XP. The contents of the etc folder in Windows 7 are different from Windows 8. In Windows 8, there are two more files in the etc folder: hosts.backup and hosts.rollback. The complete contents of the etc folder Windows 8 hosts, lmhosts.sam, networks, protocol, services, hosts.backup and hosts.rollback. Viruses usually change the contents of two files: hosts file in the etc folder and the services file in the etc folder. You can open files in the etc folder using notepad.
Network File Service Protocol ( Network File Server, NFS) is an open standard for providing the user with remote access to file systems. Centralized file systems created on its basis make it easier to perform daily tasks such as backup or virus scanning, and consolidated 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 middleware collaboration.
A better understanding of both the protocol itself and the details of its implementation will make it easier to cope with practical problems. This article is dedicated to NFS and consists of two logical parts: first, it describes the protocol itself and the goals set during its development, and then the implementation of NFS in Solaris and UNIX.
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.” File System Protocol Specification (NFS). It is interesting to note that Novell's strategy at that time was aimed at further improving file services. Until recently, while the movement for open source had not yet gained strength, Sun did not seek to reveal the secrets of its network solutions, but even then the company understood the importance of interoperability with other systems.
RFC 1094 contained two original specifications. By the time of its publication, Sun was already developing the next, third version of the specification, which is set out in RFC 1813 “NFS Version 3 Protocol Specification”. Version 4 of this protocol is defined in RFC 3010, NFS Version 4 Protocol.
NFS is widely used on all types of UNIX hosts, on Microsoft and Novell networks, and on IBM solutions such as the AS400 and OS/390. Although unknown outside the network kingdom, NFS is perhaps the most widespread platform-independent network file system.
Although NFS is a platform-independent system, its ancestor is UNIX. In other words, the architecture's hierarchical architecture and file access methods, including file system structure, ways of identifying users and groups, and file handling techniques, are all very similar to the UNIX file system. For example, the NFS file system, being identical in structure file system UNIX, mounted directly on it. When working with NFS on other operating systems, user identification parameters and file access rights are subject to mapping.
NFS is designed for use in a client-server architecture. The client accesses the file system exported by the NFS server through a mount point on the client. This access is usually transparent to the client application.
Unlike many client-server systems, NFS uses calls to exchange information. remote procedures (Remote Procedure Calls, RPC). Typically, the client establishes a connection to a previously known port and then, in accordance with the protocol, sends a request to perform a specific action. In the case of remote procedure calls, the client creates a procedure call and then sends it to the server for execution. Detailed description NFS will be presented below.
As an example, suppose a client has mounted the usr2 directory on the local root file system:
/root/usr2/ -> remote:/root/usr/
If a client application needs resources from this directory, it simply sends a request operating system to it and to the file name, and it provides access through the NFS client. As an example, consider the simple UNIX cd command, which “knows nothing” about network protocols. Team
Cd /root/usr2/
will place the working directory on a remote file system, “without even realizing” (the user also has no need for this) that the file system is remote.
Upon receiving the request, the NFS server will check whether given user the right to perform the requested action and, if the response is positive, will carry it out.
From the client's point of view, the process of locally mounting a remote file system using NFS consists of several steps. As mentioned, the NFS client will issue a remote procedure call to execute 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 minimum set: a port mapper service, a mount daemon, and an NFS server. .
The client mount command first communicates with the server's port translation service, which listens for requests on port 111. Most implementations of the client mount command support multiple versions of NFS, which increases the likelihood of finding a common protocol version for the client and server. The search is carried out starting from the oldest version, so when the common one is found, it will automatically become the most new version of those supported by the client and server.
(The material presented is focused on the third version of NFS, since it is most common on this moment. The fourth version is not yet supported by most implementations.)
The server's port translation service responds to requests based on the supported protocol and the port on which the mount daemon is running. The mount client program first establishes a connection to the server mount daemon and then issues 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 that are defined in RFC 1813 and listed in Table 1, gains access to the remote file system.
The meaning of most commands is intuitive and does not cause any difficulties for system administrators. The following listing, obtained using tcdump, illustrates the read command generated 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. (With UDP, if an error occurs, the complete RPC message, consisting of several UDP packets, is resent. With TCP, only the broken fragment is resent.)
NFS implementations typically support four ways to grant access rights: through user/file attributes, at the shared resource level, at the master node level, and as a combination of other access methods.
The first method is based on UNIX's built-in system of 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 provide access to files that were not intended when they were created.
Share-level access allows you to restrict rights to allow 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 NFS implementations allow you to further restrict access at the shared resource level to specific users and/or groups. For example, the Human Resources group is allowed to view information and nothing more.
Master node level access allows you to mount a file system only on specific nodes, which is generally a good idea since file systems can easily be created on any NFS-enabled nodes.
Combined access simply combines the above types (for example, shared-level access with access granted to a specific user) or allows users to access NFS only from a specific node.
Linux-related material is based on Red Hat 6.2 with kernel version 2.4.9, which ships with nfs-utils version 0.1.6. There are also newer versions: at the time of writing this article, the most Last update nfs-utils package number was 0.3.1. It can be downloaded from: .
The nfs-utils package contains the following executable files: exportfs, lockd, mountd, nfsd, nfsstat, nhfsstone, rquotad, showmount and statd.
Unfortunately, NFS support is sometimes a source of confusion for Linux administrators because 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, with the latest distributions including the latest versions of both. For previous releases, section 2.4 of the NFS-HOWTO provides a complete list functionality systems available for each kernel and nfs-utils package combination. The developers maintain backward compatibility of the package with earlier versions, paying a lot of attention to ensuring security and eliminating software errors.
NFS support should be initiated during kernel compilation. If necessary, the ability to work with NFS version 3 should be added to the kernel.
For distributions that support linuxconf, it is easy to configure NFS services for both clients and servers. However, the quick way to install NFS using linuxconf does not provide information about what files were created or edited, which is very important for the administrator to know the situation in the event of a system failure. The NFS architecture 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 more earlier versions BSD, defines the file systems 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 means to fine tuning. This text file, consisting of entries, empty lines, or commented lines (comments begin with a # symbol).
Let's say we want to give clients read-only access to the /home directory on the Lefty node. 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 accessible using the rpc.mountd mount daemon:
# exportfs -r exportfs: There is no hostname specified in /home (ro), enter *(ro) to avoid the warning #
When run, the exportfs command issues a warning 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 which resources can be viewed using 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 default values used by NFS. The details will be described below. To provide access to the /home directory, you must start the appropriate NFS services:
# portmap # rpc.mountd # rpc.nfsd # rpc.statd # rpc.rquotad
At any time after starting the mount daemon (rpc.mountd), check separate files available for output, you can view 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 parameter:
# showmount -e Export list for lefty: /home (everyone) #
Jumping ahead a bit, the showmount command can also be used to determine all mounted file systems, or in other words, to find out which nodes 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 stated above, most NFS implementations support various versions of this protocol. The Linux implementation allows you to limit the list of NFS versions that can be launched by specifying the -N switch for the mount daemon. For example, to run NFS version 3, and only version 3, enter the following command:
# rpc.mountd -N 1 -N 2
Fastidious users may find it inconvenient that Linux daemon NFS (rpc.nfsd) waits for version 1 and 2 packets, although this has 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 among the components of the package in relation to different versions protocol.
Access to the Lefty configured above, exported NFS file system on Linux based, depends on the client operating system. The installation style for most UNIX family operating systems is the same as that of either the original Sun OS and BSD systems or the newer Solaris. Since this article is about both Linux and Solaris, let's look at the Solaris 2.6 client configuration from the point of view of establishing a connection with the Linux version of NFS that we described above.
Thanks to features inherited from Solaris 2.6, it can be easily configured to act as an NFS client. This requires only one command:
# mount -F nfs 192.168.1.254:/home /tmp/tmp2
Let's pretend that previous command mount is successful, then the mount command without parameters 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 received on the Lefty node after the user issued the ls /tmp/tmp2 command on the Sunny node:
# 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 :43.491463 lefty. mcwrite.n.nfs > sunny.2191983954: reply ok 120 access c0001 (DF) 06:07:43.492296 sunny.2191983955 > lefty.mcwrite.n.nfs: 152 readdirplus fh 0.1/16777984 1048 bytes @ 0x000 000000 (DF) 06:07:43.492417 lefty.mcwrite.n.nfs > sunny.2191983955: reply ok 1000 readdirplus (DF)
We see that node Sunny requests a file handle (fh) for ls, to which node Lefty responds with OK and returns the directory structure. Sunny then checks the permission to access the contents of the directory (132 access fh) and receives a permission response from Lefty. The Sunny node then reads the entire contents of the directory using the readdirplus routine. Remote procedure calls are described in RFC 1813 and are listed at the beginning of this article.
Although the command sequence for accessing remote file systems is very simple, a number of circumstances can lead to the system not being mounted correctly. 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 problems associated with NFS are due to a mismatch between the client and server or incorrect server configuration.
The easiest way to troubleshoot problems on a server is from the node on which the server is running. However, when someone else administers the server for you, this is not always possible. Fast way To make sure that the corresponding server services are configured correctly, use the rpcinfo command with the -p parameter. 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 1024 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 must be corrected. If the mount fails, the following rpcinfo -p command will help you determine that the mountd service on the server is not running:
# 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 whether a particular remote process is active. The -p parameter is the most important of the switches. To see all the features of rpcinfo, see the man page.
Another useful tool is the nfsstat command. With its help, you can find out whether clients are actually accessing the exported file system, and also display statistical information in accordance with the protocol version.
Finally, one more is enough useful tool 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, produced by 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 a file test.c , which also does not lead to success.
If the file system is mounted, most common errors are related to normal UNIX permissions. Using a uid or NIS+ on Sun helps avoid setting permissions globally on all file systems. Some administrators practice "open" directories, where read access is given to "the whole world." However, this should be avoided for safety reasons. Security concerns aside, this approach is still a bad practice, since users rarely create data with the intention of making it readable by everyone.
Access by a privileged user (root) to mounted NFS file systems is treated differently. To avoid giving a privileged user unlimited access, requests from the privileged user are treated as if they were coming from the user nobody. This powerful mechanism limits privileged user access to globally readable and writable files.
Configuring Solaris to operate as an NFS server is as easy as it is with Linux. However, the commands and file locations are slightly different. When Solaris boots up, upon reaching run level 3, 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, enter:
#/usr/lib/nfs/nfsd
Beginning 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. Let's say we want to allow remote hosts to mount /export/home. To do this, enter the following command:
Share -F nfs /export/home
Some NFS system services on Linux based 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 generate 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 as follows: the comparison is first made 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 this last requirement and provide a very high level of security, you can add the following entry to the end of /etc/hosts.deny:
After this, you can use /etc/hosts.allow to set one or another operating mode. 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 rquotad:192.168.1.0/255.255.255.0 statd:192. 168.1.0/255.255.255.0
This allows a specific type of access to hosts before granting application-level access. IN Linux access at the application level, it is controlled by the /etc/exports file. It consists of entries in the following format:
Export directory (space) host|network(options)
An "export directory" is a directory that the nfsd daemon is allowed to process requests for. A "host|network" is the host or network that has access to the exported file system, and the "options" define the restrictions that the nfsd daemon imposes on the use of this shared resource - read-only access or user id mapping. .
The following example gives 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.
In Solaris, the ability to provide access to NFS is similar to Linux, but in this case, restrictions are set using certain parameters 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 man page for share_nfs details granting access using control lists on Solaris.
NFS and RPC are not without holes. Generally speaking, NFS should not be used when surfing the Internet. You can't poke holes in firewalls to allow any kind of access via NFS. It is important to keep a close eye on any emerging RPC and NFS patches, and numerous sources of security information can help. The two most popular sources are Bugtraq and CERT:
The first one can be viewed regularly in search of the necessary information or by subscribing to periodic newsletters. The second one provides, perhaps, not as prompt information as compared to others, but in a fairly complete volume and without the shade of sensationalism characteristic of some sites dedicated to information security.
What's it like practical use file /etc/networks? As far as I understand, you can specify network names in this file. For example:
Root@fw-test:~# 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 root@fw-test:~#
However, if I try to use this network name for example in the ip utility, it doesn't work:
root@fw-test:~# ip route add google-dns via 104.236.63.1 dev eth0 Error: an inet prefix is expected rather than "google-dns". root@fw-test:~# ip route add 8.8.4.4 via 104.236.64.1 dev eth0 root@fw-test:~#What is the practical use of the /etc/networks file?
As stated on the man page, the /etc/networks file must describe symbolic names for networks. With networking, this means a network address with a tail.0 at the end. Only supported simple networks class A, B or C.
In your example, the google-dns entry is incorrect. 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. The entry in /etc/network could look like this:
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 is unlikely to be relevant. Also you put the hostname in /etc/networks and not the network name!
Entries from /etc/networks are used by tools that attempt to convert numbers to names, such as the (deprecated) 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!
Sometimes networks and other system errors Windows errors may be related to problems in the Windows registry. Several programs can use networks file, but when these programs are removed or modified, sometimes "orphaned" (incorrect) Windows registry entries are left behind.
Basically, this means that while the actual path of the file may have changed, its incorrect former location is still recorded in the Windows Registry. When Windows tries to look up these incorrect file references (file locations on your PC), a networks. Additionally, a malware infection may have corrupted registry entries associated with Microsoft Windows. Thus, these corrupted Windows registry entries need to be fixed to fix the problem at the root.
Manually editing the Windows registry to remove invalid networks keys is not recommended unless you are a PC service professional. Mistakes made when editing the registry can render your PC inoperable and cause irreparable damage to your operating system. In fact, even one comma placed in the wrong place can prevent your computer from booting!
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, you can automate the process of finding corrupted registry entries, missing file references (such as networks causing the error), and broken links within the registry. Before each scan, a backup copy, which allows you to undo any changes with one click and protects you from possible damage computer. The best part is that eliminating registry errors can dramatically improve system speed and performance.
Warning: If you are not experienced user PC, we DO NOT recommend manually editing the Windows registry. Incorrect use of Registry Editor can lead to serious problems and demand Windows reinstallation. We do not guarantee that problems resulting from incorrect use of Registry Editor can be corrected. You use Registry Editor at your own risk.
Before manually restoring Windows registry, you need to create a backup by exporting the part of the registry related to networks (for example, Microsoft Windows):
The following steps for manually editing the registry will not be described in this article, as they are likely to damage your system. If you would like more information about editing the registry manually, please check out the links below.
Good afternoon, dear readers. I am publishing the second part. In the current part the main emphasis is 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).
To work with network protocols TCP/IP in Linux is enough to have only loopback interface, but if it is necessary to connect hosts with each other, naturally, it is necessary to have a network interface, data transmission channels (for example, twisted pair), perhaps some network equipment. Also, it is necessary to have installed ones (, etc.), usually supplied to. It is also necessary to have a network (for example /etc/hosts) and network support.
Let's start understanding Linux network mechanisms with manual network configuration, that is, with the case when IP address network interface static. So, when setting up a network, you need to consider and configure the following parameters:
IP address- as already mentioned in the first part of the article - this is the 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 relates to the network/subnet address, and which part to the host address. A subnet mask is a number that is added (in binary form) with an IP address to determine which subnet the address belongs to. For example, the address 192.168.0.2 with a mask of 255.255.255.0 belongs to the subnet 192.168.0.
Subnet address- determined by the subnet mask. However, 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. Typically, it is equal to the subnet address with a host value of 255, that is, for the subnet 192.168.0 the broadcast will be 192.168.0.255, similarly, for the subnet 192.168 the broadcast will be 192.168.255.255. There is no broadcast address for loopback interfaces.
Gateway IP address- this is the address of the machine that is the default gateway for communication with the outside world. There can be several gateways if the computer is connected to several networks at the same time. The gateway address is not used on isolated networks (not connected to global network), 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 host names into IP addresses. Usually provided by the provider.
To understand how the network works in Linux, I would definitely recommend reading 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, be it launching bash or a daemon. Yes, that's all Linux boot is based on, which describes the entire sequence of launching small utilities with various parameters, which 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 I think the general picture will be clear after reading. If you look at the start scripts of the network subsystem of any Linux distribution, then how to configure the network configuration using configuration files, it will become more or less clear, for example, in Debian (let’s take this distribution as a basis), a script is responsible for initializing the network /etc/init.d/networking, having looked at 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 the presence of mounted network file systems ( check_network_file_systems(), check_network_swap()), as well as checking the existence of some still unclear config /etc/network/options ( function process_options()), and at the very bottom, 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 same " certain actions", using the start argument as an example, you can see that the function is launched first process_options, then the phrase is sent to the log Configuring network interfaces, and the command is run ifup -a. If you look at man ifup , you can see that this command reads the config from a file /etc/network/interfaces and according to the key -a launches 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.
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-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.
In this config the lines allow-hotplug And auto- these are synonyms and interfaces will be raised on command ifup -a. This, in fact, is the entire chain of operation of the network subsystem. Similarly, in other distributions: in RedHat and SUSE the network is launched by a script /etc/init.d/network. Having examined it, you can similarly find where the network configuration lies.
This file stores 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 was used instead 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 in your network is measured in units, and not in tens or hundreds, because in this case, you will have to monitor the correctness of this file on each machine.
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, do not add a route route add 192.168.1.12 , A route add.
File defines hostname lookup order/network, 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.
The file specifies name resolution parameters for the resolver
Ip-server:~# cat /etc/host.conf multi on
This file tells the resolv library to return all valid host addresses that appear in the /etc/hosts file, and not just the first one.
This file defines the parameters of the mechanism for converting network names to IP addresses. In simple terms, 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 an FQDN name, then this domain will be substituted as an “end”. For example, when executing the ping host command, the pinged address is converted to host.domain.local. The remaining parameters can be read in man resolv.conf. Very often, Linux uses 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 that use 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 resolveconf.
After reviewing the main configuration files, you can look at . The command has already been mentioned above ifup, ifdown, but these tools are not entirely universal; for example, RH distributions do not have these commands by default. In addition, new distributions have introduced a new high-level network management tool - which belongs to the iproute package. I will dedicate it to him (the iproute package). And in the current post I will not consider it. The commands described below belong to .
So, to be sure that the command works on any Linux distribution, you need to use two main old commands. This , and arp. The 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 executing 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, you can understand that the script /etc/init.d/networking the next time it starts, it will re-read the above configs and apply the old settings. Accordingly, the way out for permanently setting the settings is either to enter the ifconfig command with the appropriate parameters in , or to manually correct the corresponding configs of the network interfaces.
Also, if the command is executed ifconfig with missing parameters(for example, only an IP address), then the rest are added automatically (for example, a 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 existing interfaces in modern kernels it 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 gateway field for such entries indicates the address of the output interface or *. In older versions of the kernel (I can’t tell you the kernel number from which routes began to rise automatically), it was necessary to add the route manually.
If there is a need to organize your routes, then you need to use . With this command you can add and remove routes, but again, this will only help until you restart /etc/init.d/networking (or another script responsible for the network in your distribution). In order for routes to be added automatically, you must, in the same way as with the ifconfig command, add commands for adding routes to rc.local, or manually correct the corresponding network interface configs (for example, in Deb - /etc/network/options).
By what rules routes to networks are formed, I'm in
There are a large number of network diagnostic tools in Linux, often very similar to utilities from Microsoft. I will look at 3 main network diagnostic utilities, without which it will be difficult to identify problems.
I think that this utility is familiar to almost everyone. This utility works by sending so-called ICMP packets to the remote server, which will be specified in the command parameters, the server returns the sent commands, and pingcounts the 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 64 bytes from www.yandex.ru (87.250.251.3): icmp_seq=2 ttl=57 time=43.2 ms 64 bytes 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.500 ms
As can be seen from the above example, ping gives us a bunch of useful information. First of all, we found out that we can establish a connection with the host ya.ru(sometimes they say that “the 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= numbering of sent packets is indicated. Each sent packet is sequentially assigned a number, and if there are “dips” in this numbering, this will tell us that the connection with the “pinged” is unstable, and 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 It is interesting because it can allow you to see exactly where the problems occurred. Let's say ping utility displays a message network not reachable (network not available), or other similar message. This most likely indicates that your system is configured incorrectly. In this case, you can send packets to the provider’s IP address to understand where the problem occurs (between the local PC or “further”). If you are connected to the Internet through a router, you can send packets via its IP. Accordingly, if the problem appears already at this stage, this indicates incorrect configuration of the local system, or damage to the cable; if the router is recalled, but the provider’s server is not, then the problem is in the provider’s communication channel, etc. Finally, if the name to IP conversion fails, then you can check the IP connection; if the responses come correctly, then you can guess that the problem is in the DNS.
It should be noted that this utility is not always a reliable diagnostic tool. The remote server can block responses to ICMP requests.
In simple terms, the command is called route tracing. As the name suggests, this utility will show which route the packets took to reach 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 1 243-083-free.kubtelecom.ru (213.132.83.243) 6.408 ms 6.306 ms 6.193 ms 2 065-064-free .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 KubTelecom-lgw.Krasnodar.gldn.net (194.186.6.177) 81.430 ms 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 4 1.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 provider’s router 243-083-free.kubtelecom.ru (213.132.83.243) (South of Russia) to the end host at www.yandex.ru (213.180.204.3) in Moscow.
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: printcmd ;; 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 not necessary to specify, in this case the source of information about DNS will be 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 domain IP addresses, 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.
ping, dig and other diagnostic utilities with parameters can be found in the post.
Connecting and launching a new network card comes down to a few steps:
1. Physical connection of the card
3. View the output of whether the system has detected a new network card:
Let's see the conclusion 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: N IC 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 one 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 has appeared - eth3, which is actually eth2, but 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. All that's left is to set up the new interface in /etc/network/interfaces(Debian) because this map was not initialized by the startup script /etc/init.d/network. ifconfig sees this map:
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 again - it does not configure. How to configure the network card was discussed above.
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 split the article into two. In total, I tried to present, not a step-by-step procedure for setting up a network, but to outline the principle and explain the understanding of how the network starts and works in Linux. I really hope that I succeeded. I will be glad to see your comments and additions. Over time, I will add to the article.
