Quickly Setting Up PLIP and NFS
NFS (Networked File System) allows you to access remote file systems of other computers through a network connection. In other words, you can manipulate files on another computer directly, as if they were files on your own computer. Your kernel must have NFS support enabled (default on Slackware), and you need to run programs (called “daemons”) which listen to the network for connection requests and act accordingly when one is received. You also need to specify which directories can be accessed and which hosts are allowed to access them.
NFS is an even better way to access files between the two computers than using ftp or rcp. (To have NFS support enabled, the option is CONFIG_NFS_FS=y; again, this is the default with Slackware.) The setup described here allows you to consider the disk of hermes as being a disk on zeus, thereby allowing you to access all the files directly without having to log in (as with ftp) or setting rhosts access (as with rcp). Before you start, check your user identification number (UID) on both machines using the command id:
zeus:~> id uid=401(zeusname) gid=100(users) groups=100(users) hermes:~> id uid=401(hermname) gid=100(users) groups=100(users)
I will assume that both numbers to the right of “uid=” match. (This number could be something other than 401.) If they do not match, refer to the section ahead called “If UIDs Don't Match”. Now take the following steps (described in the next three sections):
Start the RPC (remote procedure call) daemons in the /etc/rc.d/rc.inet2 file.
Create a list of hermes directories to be exported.
Mount the exported directories of hermes on zeus.
On hermes, check that the rpc daemons are launched in the /etc/rc.d/rc.inet2 file. These daemons process the network requests to handle NFS. They are launched by default in Slackware, so if you haven't changed the re.inet2 file from the original distribution, there is nothing to do, and you can skip the rest of this section.
First, type ps a | grep rpc to check that the daemons are running. On my system, I get this output:
hermes:~> ps a | grep rpc 80 ? S 0:00 /usr/sbin/rpc.mountd 83 ? S 0:00 /usr/sbin/rpc.nfsd 74 ? S 0:00 /usr/sbin/rpc.portmap
If they are not running, edit the /etc/rc.d/rc.inet2 file (make a backup copy first) and append the lines:
/usr/sbin/rpc.portmap /usr/sbin/rpc.mountd /usr/sbin/rpc.nfsdIf you make any changes to the /etc/rc.d/rc.inet2 file, reboot the computer and check to be sure the daemons are now running. These commands could always be issued as root from the command line instead of rebooting.
On hermes, edit the /etc/exports file, which contains the directories you wish to make accessible from zeus. You have to choose which directories you want to export. You could just export the root directory /, thus exporting the whole disk; but usually you just want to access the user files located in /home, so in this example I export only /home. Add the following line to the /etc/exports file:
See the exports(5) man page for the format of the file and the available options. In particular, you will be able to write from zeus onto hermes' disk; if you don't think this is a good idea, use:
/home zeus(ro)The option ro stands for “read-only”. Notice that user root cannot write on hermes' disk from zeus unless you specifically allow it using the options described in exports(5). You can add other directories, one on each line, using the same syntax.
Now tell the nfsd and mountd daemon that the exports file has changed by sending them a signal using the command:
hermes# killall -HUP rpc.nfsd rpc.mountd
From zeus, you can check that hermes is now ready to export by issuing the command:
zeus# /usr/sbin/showmount -e hermes Export list for hermes: /home zeus
Finally, on zeus, chose a “mount point”; this is just an empty directory that you will use to access the remote directory on hermes. I suggest:
zeus# mkdir /nfs zeus# mkdir /nfs/hermesReady to mount? From zeus type:
zeus# /sbin/mount -t nfs hermes:/home /nfs/hermesAll the files on hermes in directory /home are now accessible from zeus. Type:
zeus:~> ls /nfs/hermes/hermnameand you will see the listing of all your files on hermes (if your account has “hermname” as user name). Once you are finished and wish to shutdown the notebook computer, unmount hermes' file system by giving:
zeus# /sbin/umount /nfs/hermesthen close the connection using the script, plip-off.sh.
I can even make things a bit more comfortable by adding the following line in the file /etc/fstab on zeus:
hermes:/home /nfs/hermes nfs noauto 0 0
This command tells Linux to add to its list of file systems the directory /home on host hermes, which has to be mounted under /nfs/hermes on zeus, but not automatically (in particular, not at boot time), and that hermes has the type nfs. (See the man pages nfs(5), filesystems(9), fstab(4) for details.) By adding that line, the mount command is reduced to:
zeus# /sbin/mount /nfs/hermesFinally, if you are using PLIP solely to use NFS, you could add the mount command at the end of the zeus script plip-on.sh and umount at the beginning of plip-off.sh. In this case, you must start PLIP first on hermes and shut it down first on zeus, otherwise mount cannot reach the network.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- SourceClear Open
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide