File Sharing, RPMs, DHCP

Network File System (NFS) is a file-sharing mechanism that allows for the relatively seamless sharing of files across multiple networked machines. It works by allowing client systems to mount an NFS "share" (as in "shared disk") from an NFS server as though it were a local disk.


I need to set up some simple file sharing. What is NFS and how do I set it up?

Network File System (NFS) is a file-sharing mechanism that allows for the relatively seamless sharing of files across multiple networked machines. It works by allowing client systems to mount an NFS “share” (as in “shared disk”) from an NFS server as though it were a local disk.

Of course, this comes with some obvious risks. If misapplied, or insecure, it could allow a malicious user to cause all kinds of mischief on a system. So correct configuration is critical. One specific configuration detail worth paying special attention to is that NFS systems rely purely on IP address or hostname for identification and authentication. So it’s a good idea to be very specific about which machines will be allowed to connect to the server.

If you want to give NFS a spin, you will need to first grab a copy and ensure that support for it has been compiled into your Linux kernel.

Linux kernels support generic NFSv2 as standard, and kernels 2.4+ have full NFSv3 support. The requisite software can be downloaded from http://nfs.sourceforge.net/. Documentation on how to install the NFS software is also available from this site.

Once this is done, from the server side, it is necessary to configure which directories will be exported to which clients, and with what options.

This is done by making an entry in /etc/exports. This entry will typically look something like Listing One.

Listing One: /etc/export Entry

Sharedir Computer1(option,option,option) Computer2(option, option)

Sharedir will mean the directory that you wish to share on the server.

Computer1 and Computer2 refer to the individual machines that these directories will be shared with. These may be notated as IP addresses, DNS names, or network identifiers.

Option refers to the options the share will make available to that computer. Some of these include:

*no_root_squash: this allows for the root user on the client machine to maintain those privileges when writing to the share. That is, they will be entitled to write files as if they are also root on the server.

*rw and ro: these options specify whether the share will be “read/ write” or “read/only”. By default, NFS shares are read only, but can very easily be read/write.

So an example /etc/exports file may look something like what is shown in Listing Two. This would allow for sharing of /home to all the machines that are located on the 192.168.0/24 subnet, while also giving them permission to read and write.

Listing Two: Sample /etc/export File


To then actually use these shares on a client machine, the process is fairly simple. All it takes is a simple mount command:

#  mount servername:/sharedir/mountpoint


# mount

Shared directories, like any normal system mount, can be just as easily removed with:


Similar to local filesystems, shared directories can be added to /etc/fstab for mounting at boot time. However, if any of these machines are going to be connected directly to the Internet at large, or have some form of public or distrusted availability, close consideration should be given to using firewalling mechanisms or connection restrictions to limit access to the file server.

More information can be found in the NFS-HOWTO at http://nfs.sourceforge.net/nfs-howto/index.html.


What are these “RPM” packages I keep seeing on my machine? How do they work, and can I force an installation?

RPM files, or Red Hat Package Manager files, are simply archives of files used for the distribution of software applications. Similar to files that have been zipped or tarred, they contain the compressed images of any number of files that make up a given software package. Generally speaking, they’re pre-compiled or “binary” software that is ready for installation. The benefit of this is that these RPMs are available from a vendor and provide a software package that can be immediately installed. If the package you are installing depends on any outside libraries or other programs, the RPM can also check to make sure that those required programs are already installed on your system.

That said, how are these packages installed outside of a GUI tool? It’s a fairly simple process. Say for example, we’d like to install programZ.i386.rpm, which is the latest and greatest of programZ, as acquired from http://rpmfind.net/. It is first necessary to attempt a flat installation, as you can see in Listing Three.

Listing Three: Flat RPM Installation

# rpm -Uvh  programZ.i386.rpm programZ ##################################################

In this case, I’ve asked the machine to (-U)pdate/install the software, to be (-v)erbose about what is going on, and to print (-h)ash marks.

Now, say there is another program altogether, appF, which we no longer want on our machine. What is involved in removal? It’s quite simple:

# rpm -e appF

This will promptly (-e)rase the application from the machine, assuming that it wasn’t required by another program. In the case of a dependency conflict, where some other package was reliant on appF, or something that it provided, there are two ways of handling the situation.

First and foremost, it may be the best practice to remove all packages that are dependent on the package you are about to remove. However, situations may sometimes arise where you know it is in the best interests of all involved to be able to forcibly remove the package. This can be done by using the (-force) options with RPM, which you can read up on in its documentation — (man rpm).

Another useful trick with packages, especially for those with uncertain names, is to be able to “query” them, or ask them what they are. Packages come with header information that is invaluable in helping to decipher the myriad of RPM files available on the Web today. For uninstalled packages, this can be done fairly quickly:

# rpm -qpi applicationFiles.0.3.2.rpm

This will then present some nicely formatted metadata with regards to the package. This metadata often includes: author, license, size, description, software group, build dates, and so on. This is extremely useful if you’re trying to learn more about a mystery package lying around on a disk.


What’s a fast way to get a DHCP client connection up?

In all honesty, it depends on what you have installed. Generally speaking, there are three applications that will allow you to quickly obtain an IP address and start using the network. These are dhclient, dhcpcd, and pump.

To quickly get started with dhcpcd, grab a package from your install disks or from your vendor’s official site. Once done, it is a simple case of executing:

# /sbin/dhcpcd

This will load the DHCP client daemon, which will maintain the DHCP address. Of course, it would be better to add this to your boot-up scripts. Even better, if you have a package from your vendor, you might be able to simply use some stop-start scripts. dhcpcd can be used on several global network services. Check out the dhcpcd site at http://www.phystech.com/download/dhcpcd.html.

An alternative to dhcpcd is pump. Working in a similar manner, pump may be used to easily configure Ethernet devices. For example:

# /sbin/pump -i eth0

will attempt to configure the Ethernet device (eth0) from the resident DHCP server. Just as with dhcpcd, there are a number of different configuration options you may choose to the fixed configuration files.

Just to be different, you might like to consider using dhclient. This client, distributed by the ISC (Internet Software Consortium (the Bind and INN guys)) is available from http://www.isc.org/products/DHCP/. As with the others, its invocation is fairly simple:

# /sbin/dhclient

This will attempt to configure all broadcast devices on the system, should there be no /etc/dhclient.conf file present. Should you wish to only configure one interface, it is generally necessary to set up the config file similar to Listing Four.

Listing Four: Configuring a Single Interface

interface “eth0″ {
send dhcp-client-identifier 1:xx:xx:xx:xx:xx:xx;
send dhcp-lease-time 65400;

This assumes that eth0 is the device, and 1:xx:xx:xx:xx:xx:xx is the mach address of the network card you wish to configure.

So, as you can see, it may be possible to set up your network card with programs you already have installed. Try giving these applications a go.

Quentin Cregan is a tech and security consultant and sometime student hailing from Australia. He can be reached at qc@sensed.com.

Comments are closed.