[ Pobierz całość w formacie PDF ]
.'s to get fromthe directory containing the link to the root on the server.This option onlymakes sense when a host's entire le system is mounted, else some of thelinks might point to nowhere, or even worse, les they were never meant topoint to. 11.5.The Linux Automounter 178This option is on by default.link absolute Leave all symbolic link as they are the normal behavior for Sun-suppliedNFS servers.map identity The map identity option tells the server to assume that the client uses thesame uid's and gid's as the server.This option is on by default.map daemon This option tells the NFS server to assume that client and server do not sharethe same uid gid space.nfsd will then build a list mapping id's betweenclient and server by querying the client's ugidd daemon.An error parsing the exports le is reported to syslogd 's daemon facility at level noticewhenever nfsd or mountd is started up.Note that host names are obtained from the client's IP address by reverse mapping, soyou have to have the resolver con gured properly.If you use BIND and are very security-conscious, you should enable spoof checking in your host.conf le.11.5 The Linux AutomounterSometimes, it is wasteful to mount all NFS volumes users might possibly want to access;either because of the sheer number of volumes to be mounted, or because of the time thiswould take at startup.A viable alternative to this is a so-called automounter.This isa daemon that automatically and transparently mounts any NFS volume as needed, andunmounts them after they have not been used for some time.One of the clever things aboutan automounter is that it is able to mount a certain volume from alternative places.Forinstance, you may keep copies of your X programs and support les on two or three hosts,and have all other hosts mount them via NFS.Using an automounter, you may specify allthree of them to be mounted on usr X386; the automounter will then try to mount anyof these until one of the mount attempts succeeds.The automounter commonly used with Linux is called amd.It was originally written byJan-Simon Pendry and has been ported to Linux by Rick Sladkey.The current version isamd-5.3.Explaining amd is beyond the scope of this chapter; for a good manual please refer tothe sources; they contain a texinfo le with very detailed information. Chapter 12Managing Taylor UUCP12.1 HistoryUUCP was designed in the late seventies by Mike Lesk at AT&T Bell Laboratories toprovide a simple dial-up network over public telephone lines.Since most people that wantto have email and Usenet News on their home machine still communicate through modems,UUCP has remained very popular.Although there are many implementations running ona wide variety of hardware platforms and operating systems, they are compatible to a highdegree.However, as with most software that has somehow become standard" over the years,there is no UUCP which one would call the UUCP.It has undergone a steady process ofevolution since the rst version which was implemented in 1976.Currently, there are twoma jor species which di er mainly in their support of hardware and their con guration.Ofthese, various implementations exist, each varying slightly from its siblings.One species is the so-called Version 2 UUCP", which dates back to a 1977 implemen-tation by Mike Lesk, David A.Novitz, and Greg Chesson.Although it is fairly old, it isstill in frequent use.Recent implementations of Version 2 provide much of the comfort ofthe newer UUCP species.The second species was developed in 1983, and is commonly referred to as BNU BasicNetworking Utilities , HoneyDanBer UUCP, or HDB for short.The name is derived fromthe authors' names, P.Honeyman, D.A.Novitz, and B.E.Redman.HDB was conceivedto eliminate some of Version 2 UUCP's de ciencies.For example, new transfer protocolswere added, and the spool directory was split so that now there is one directory for eachsite you have UUCP tra c with.179 12.1.History 180The implementation of UUCP currently distributed with Linux is Taylor UUCP 1.04,1which is the version this chapter is based upon.Taylor UUCP Version 1.04 was releasedin February 1993.Apart from traditional con guration les, Taylor UUCP may also becompiled to understand the new-style a.k.a.Taylor" con guration les.Version 1.05 has been released recently, and will soon make its way into most distribu-tions.The di erences between these versions mostly a ect features you will never use, soyou should be able to con gure Taylor UUCP 1.05 using the information form this book.As included in most Linux distributions, Taylor UUCP is usually compiled for BNUcompatibility, or the Taylor con guiration scheme, or both.As the latter is much moreexible, and probably easier to understand than the often rather obscure BNU con gurationles, I will describe the Taylor scheme below.The purpose of this chapter is not to give you an exhaustive description of what thecommand line options for the UUCP commands are and what they do, but to give you anintroduction on how to set up a working UUCP node.The rst section gives a hopefullygentle introduction about how UUCP implements remote execution and le transfers.If youare not entirely new to UUCP, you might want to skip this and move on to section UUCPCon guration Files, which explains the various les used to set up UUCP.We will however assume that you are familiar with the user programs of the UUCP suite.These are uucp and uux.For a description, please refer to the on-line manual pages.Besides the publicly accessible programs, uux and uucp, the UUCP suite contains anumber of commands used for administrative purposes only.They are used to monitorUUCP tra c across your node, remove old log les, or compile statistics.None of these willbe described here, because they're peripheral to the main tasks of UUCP.Besides, they'rewell documented and fairly easy to understand.However, there is a third category, whichcomprises the actual UUCP work horses".They are called uucico where cico stands forcopy-in copy-out , and uuxqt, which executes jobs sent from remote systems.12.1.1 More Information on UUCPThose who don't nd everything they need in this chapter should read the documentationthat comes along with the package.This is a set of texinfo les that describe the setupusing the Taylor con guration scheme.Texinfo can be converted to DVI and to GNU infoles using tex and makeinfo, respectively.If you want to use BNU or even shudder! Version 2 con guration les, there is a verygood book, Managing UUCP and Usenet" OReilly89.I nd it very useful.Another1Written and copyrighted by Ian Taylor, 1993. 12.2.Introduction 181good source for information about UUCP on Linux is Vince Skahan's UUCP-HOWTO,which is posted regularly to comp.os.linux.announce.There's also a newsgroup for the discussion of UUCP, called comp.mail.uucp.If youhave questions speci c to Taylor UUCP, you may be better o asking them there, ratherthan on the comp.os.linux groups.12.2 Introduction12.2.1 Layout of UUCP Transfers and Remote ExecutionVital to the understanding of UUCP is the concept of jobs.Every transfer a user initiateswith uucp or uux is called a job.It is made up of a command to be executed on a remotesystem, and a collection of les to be transferred between sites.One of these parts may bemissing.As an example, assume you issued the following command on your host, which makesUUCP copy the le netguide.ps to host pablo, and makes it execute the lpr command toprint the le.$ uux -r pablo! lpr ! netguide.psUUCP does not generally call the remote system immediately to execute a job else youcould make do with kermit.Instead, it temporarily stores the job description away [ Pobierz całość w formacie PDF ]

  • zanotowane.pl
  • doc.pisz.pl
  • pdf.pisz.pl
  • hanula1950.keep.pl

    		•