Ftp Web Hosting - J2Ee Hosting Sun Java Developing Blog

There’s also a newsgroup for the discussion of UUCP called comp.mail.uucp. If you have questions specific to Taylor UUCP, you may be better off asking them there, rather than on the comp.os.linux.* groups. UUCP Transfers and Remote Execution The concept of jobs is vital to understanding UUCP. Every transfer that a user initiates with uucpor uuxis called a job. It is made up of a command to be executed on a remote system, a collection of files to be transferred between sites, or both. As an example, the following command makes UUCP copy the file netguide.ps to a remote host named pablo and execute the lpr command on pablo to print the file: $ uux -r pablo!lpr !netguide.ps UUCP does not generally call the remote system immediately to execute a job (or else you could make do with kermit). Instead, it temporarily stores the job description away. This is called spooling. The directory tree under which jobs are stored is therefore called the spool directory and is generally located in /var/spool/uucp. In our example, the job description would contain information about the remote command to be executed (lpr), the user who requested the execution, and a couple of other items. In addition to the job description, UUCP has to store the input file netguide.ps. The exact location and naming of spool files may vary, depending on some compile-time options. HDB- compatible UUCPs generally store spool files in a /var/spool/uucp subdirectory with the name of the remote site. When compiled for Taylor configuration, UUCP creates subdirectories below the site-specific spool directory for different types of spool files. At regular intervals, UUCP dials up the remote system. When a connection to the remote machine is established, UUCP transfers the files describing the job, plus any input files. The incoming jobs will not be executed immediately, but only after the connection terminates. Execution is handled by uuxqt, which also takes care of forwarding any jobs that are designated for another site. To distinguish between more and less important jobs, UUCP associates a grade with each job. This is a single digit ranging from 0 through 9, A through Z, and a through z, in decreasing precedence. Mail is customarily spooled with grade B or C, while news is spooled with grade N. Jobs with higher grades are transferred earlier. Grades may be assigned using the -g flag when invoking uucpor uux. You can also prohibit the transfer of jobs below a given grade at certain times. To do this we set the maximum spool grade that will be prohibited during a conversation. The maximum spool grade defaults to z, meaning all grades will be transferred every time. Note the semantic ambiguity here: a file is transferred only if it has a grade equal to or above the maximum spool grade threshold. The Inner Workings of uucico To understand why uucico needs to know particular information, a quick description of how it actually connects to a remote system is helpful. When you execute uucico -s system from the command line, uucico first has to connect physically. The actions taken depend on the type of connection to open. Thus, when using a telephone line, it has to find a modem and dial out. Over TCP, it has to call gethostbyname to convert the name to a network address, find out which port to open, and bind the address to the corresponding socket. A successful connection is followed by authorization. This procedure generally consists of the remote system asking for a login name and possibly a password. This exchange is commonly called the login chat. The authorization procedure is performed either by the usual getty/login suite, or on TCP sockets by uucico itself. If authorization succeeds, the remote end fires up uucico. The local copy of uucico that initiated the connection is referred to as master, and the remote copy as slave. Next follows the handshake phase: the master sends its hostname plus several flags. The slave checks this host- name for permission to log in, send, and receive files, etc. The flags describe (among other things) the maximum grade of spool files to transfer. If enabled, a conversation count or call sequence number check takes place here.

Chapter 16 - Managing Taylor UUCP UUCP was designed in the late seventies by Mike Lesk at AT&T Bell Laboratories to provide a simple dialup network over public telephone lines. Despite the popularity of dialup PPP and SLIP connections to the Internet, many people who want to have email and Usenet News on their home machine still use UUCP because it is often cheaper, especially in countries where Internet users have to pay by the minute for local telephone calls, or where they do not have a local ISP and must pay long distance toll rates to connect. Although there are many implementations of UUCP running on a wide variety of hardware platforms and operating systems, overall, they are highly compatible. However, as with most software that has somehow become “standard” over the years, there is no UUCP that one would call the UUCP. It has undergone a steady evolution since the first version was implemented in 1976. Currently, there are two major species that differ mainly in their hardware support and configuration. Of these two, various implementations exist, each varying slightly from its siblings. One species is known as Version 2 UUCP, which dates back to a 1977 implementation by Mike Lesk, David A. Novitz, and Greg Chesson. Although it is fairly old, it is still frequently used. Recent implementations of Version 2 provide much of the comfort that the newer UUCP species do. The second species was developed in 1983 and is commonly referred to as BNU (Basic Networking Utilities) or HoneyDanBer UUCP. The latter name is derived from the authors’ names (P. Honeyman, D. A. Novitz, and B. E. Redman) and is often shortened further to HDB, which is the term we’ll use in this chapter. HDB was conceived to eliminate some of Version 2 UUCP’s deficiencies. For example, new transfer protocols were added, and the spool directory was split so that now there is one directory for each site with which you have UUCP traffic. The implementation of UUCP currently distributed with Linux is Taylor UUCP 1.06, which is the version this chapter is based upon.89 Taylor UUCP Version 1.06 was released in August 1995. Apart from traditional configuration files, Taylor UUCP can also be compiled to understand the newstyle — a.k.a. Taylor — configuration files. Taylor UUCP is usually compiled for HDB compatibility, the Taylor configuration scheme, or both. Because the Taylor scheme is much more flexible and probably easier to understand than the often obscure HDB configuration files, we will describe the Taylor scheme below. This chapter is not designed to exhaustively describe the command-line options for the UUCP commands and what they do, but to give you an introduction to how to set up a working UUCP node. The first section gives a gentle introduction about how UUCP implements remote execution and file transfers. If you are not entirely new to UUCP, you might want to skip to the section “UUCP Configuration Files” later in this chapter, which explains the various files used to set up UUCP. We will, however, assume that you are familiar with the user programs of the UUCP suite, uucp and uux. For a description, refer to the online manual pages. Besides the publicly accessible programs uucp and uux, the UUCP suite contains a number of commands used for administrative purposes only. They are used to monitor UUCP traffic across your node, remove old log files, or compile statistics. None of these will be described here because they are peripheral to the main tasks of UUCP. Besides, they’re well documented and fairly easy to understand; refer to the manual pages for more information. However, there is a third category, which comprise the actual UUCP “work horses.” They are called uucico (where cico stands for copy-in copy-out), and uuxqt, which executes jobs sent from remote systems. We concentrate on these two important programs in this chapter. If you’re not satisfied with our coverage of these topics, you should read the documentation that comes with the UUCP package. This is a set of Texinfo files that describe the setup using the Taylor configuration scheme. You can convert the Texinfo files into a dvi file using the texi2dvi (found in the Texinfo package in your distribution) and view the dvi file using the xdvi command. Guylhem Aznar’s UUCP-HOWTO is another good source for information about UUCP in a Linux environment. It is available at any Linux Documentation Project mirror and is posted regularly to comp.os.linux.answers. Written and copyrighted by Ian Taylor, 1995.

Managing Print Queues The pqlist command lists all of the print queues available to you on the specified server. If you do not specify a fileserver on the command line using the -S option, or a login name and password, these will be taken from the default entry in your ~/.nwclient file: # pqlist -S vbrew_f1 -U guest -n Server: ALES_F1 Print queue name Queue ID TEST AA02009E Q2 EF0200D9 NPI223761_P1 DA03007C Q1 F1060004 I-DATA 0D0A003B NPI223761_P3 D80A0031 Our example shows a list of the print queues available to the guest user on the ALES_F1 fileserver.88 To view the print jobs on a print queue, use the pqstat command. It takes the print queue name as an argument and lists all of the jobs in that queue. You may optionally supply another argument indicating how many of the jobs in the queue you’d like to list. The following sample output has been compressed a bit to fit the width of this book’s page: $ pqstat -S ALES_F1 NPI223761_P1 Server: ALES_F1 Queue: NPI223761_P1 Queue ID: 6A0E000C Seq Name Description Status Form Job ID 1 TOTRAN LyX document -proposal.lyx Active 0 02660001 We can see just one print job in the queue, owned by user TOTRAN. The rest of the options include a description of the job, its status, and its job identifier. The pqrm command is used to remove print jobs from a specified print queue. To remove the job in the queue we’ve just obtained the status of, we’d use: $ pqrm -S ALES_F1 NPI223761_P1 02660001 The command is pretty straightforward but is clumsy to use in a hurry. It would be a worthwhile project to write a basic script to simplify this operation. NetWare Server Emulation There are two free software emulators for NetWare fileservers under Linux. lwared was developed by Ales Dryak and mars_nwe was developed by Martin Stover. Both of these packages provide elementary NetWare fileserver emulation under Linux, allowing NetWare clients to mount Linux directories exported as NetWare volumes. While the lwared server is simpler to configure, the mars_nwe server is more fully featured. The installation and configuration of these packages is beyond the scope of this chapter, but both are described in the IPX-HOWTO. It looks like the system administrators had been sampling some of the Virtual Brewery’s wares before they chose some of those print queue names. Hopefully your print queue names are more meaningful!

Using nprint with the Line Printer Daemon You will recall we previously mentioned that the -c option for the ncpmount is useful for printing. At last we’ll explain why and how. Linux usually uses BSD-style line printer software. The line printer daemon (lpd) is a daemon that checks a local spool directory for queued jobs that are to be printed. lpd reads the printer name and some other parameters from the specially formatted spool file and writes the data to the printer, optionally passing the data through a filter to transform or manipulate it in some way. The lpd daemon uses a simple database called /etc/printcap to store printer configuration information, including what filters are to be run. lpd usually runs with the permissions of a special system user called lp. You could configure nprint as a filter for the lpd to use, which allows users of your Linux machine to output directly to remote printers hosted by a NetWare fileserver. To do this, the lp user must be able to write NCP requests to the NCP connection to the server. An easy way to achieve this without requiring the lp user to establish its own connection and login is to specify lp as the owner of a connection established by another user. A complete example of how to set up the Linux printing system to handle print jobs from clients over NetWare is listed in three steps: 1. Write a wrapper script. The /etc/printcap file doesn’t permit options to be supplied to filters. Therefore, you need to write a short script that invokes the command you want along with its options. The wrapper script could be as simple as: #!/bin/sh # p2pslaser -simple script to redirect stdin to the # PSLASER queue on the REDS01 server # /usr/bin/nprint -S REDS01 -U stuart -q PSLASER # Store the script in the file /usr/local/bin/p2pslaser. 2. Write the /etc/printcap entry. We’ll need to configure the p2pslaser script we created as the output filter in the /etc/printcap. This would look something like: pslaser|Postscript Laser Printer hosted by NetWare server:\ :lp=/dev/null:\ :sd=/var/spool/lpd/pslaser:\ :if=/usr/local/bin/p2pslaser:\ :af=/var/log/lp-acct:\ :lf=/var/log/lp-errs:\ :pl#66:\ :pw#80:\ :pc#150:\ :mx#0:\ :sh: 3. Add the -c option to the ncpmount. ncpmount -S REDS01 …. -c lp …. Our local user stuart must specify the lp user as the owner of the connection when he mounts the remote NetWare server. Now any Linux user may choose to specify pslaser as the printer name when invoking lp. The print job will be sent to the specified NetWare server and spooled for printing.

Table 15.3: Linux Bindery Manipulation Tools Command Name Command Description nwbpvalues Print a NetWare bindery property’s contents nwbpadd Set the value of a NetWare bindery property nwbprm Remove a NetWare bindery property Printing to a NetWare Print Queue The ncpfs package contains a small utility called nprint that sends print jobs across an NCP connection to a NetWare print queue. This command creates the connection if it doesn’t currently exist and uses the ~/.nwclient file that we described earlier to hide the username and password from prying eyes. The command-line arguments used to manage the login process are the same as those used by the ncpmount, so we won’t go through those again here. We will cover the most important command-line options in our examples; refer to the nprint(1) manual page for details. The only required option for nprint is the name of the file to print. If the filename specified is - or if no filename is specified at all, nprint will accept the print job from stdin. The most important nprint options specify the fileserver and print queue to which you wish the job to be sent. Table 15.4 lists the most important options. Table 15.4: nprint Command-Line Options Option Description -S server_name The name of the NetWare fileserver supporting the print queue to which you wish to print. Usually it is convenient for the server to have an entry in ~/.nwclient. This option is mandatory. -q queue_name The print queue to which to send the print job. This option is mandatory. -d job_description Text that will appear in the print console utility when displaying the list of queued jobs. -l lines The number of lines per printed page. This defaults to 66. -r columns The number of columns per printed page. This defaults to 80. -c copies The number of copies of the job that will be printed. The default is 1. A simple example using nprint would look like: $ nprint -S REDS01 -q PSLASER -c 2 /home/matt/ethylene.ps This command would print two copies of the file /home/matt/ethylene.ps to the printer named PSLASER on the REDS01 fileserver using a username and password obtained from the ~/.nwclient file.

$ slist NPPWR-31-CD01 23A91330 000000000001 V242X-14-F02 A3062DB0 000000000001 QITG_284ELI05_F4 78A20430 000000000001 QRWMA-04-F16 B2030D6A 000000000001 VWPDE-02-F08 35540430 000000000001 NMCS_33PARK08_F2 248B0530 000000000001 NCCRD-00-CD01 21790430 000000000001 NWGNG-F07 53171D02 000000000001 QCON_7TOMLI04_F7 72760630 000000000001 W639W-F04 D1014D0E 000000000001 QCON_481GYM0G_F1 77690130 000000000001 VITG_SOE-MAIL_F4R 33200C30 000000000001 slist accepts no arguments. The output displays the fileserver name, the IPX network address, and the host address. Send Messages to NetWare Users NetWare supports a mechanism to send messages to logged-in users. The nsend command implements this feature in Linux. You must be logged in to the server to send messages, so you need to supply the fileserver name and login details on the command line with the destination user and the message to send: # nsend -S vbrew_f1 -U gary -P j0yj0y supervisor “Join me for a lager before we do the print queues!” Here a user with login name gary sends a tempting invitation to the person using the supervisor account on the ALES_F1 fileserver. Our default fileserver and login credentials will be used if we don’t supply them. Browsing and Manipulating Bindery Data Each NetWare fileserver maintains a database of information about its users and configuration. This database is called the bindery. Linux supports a set of tools that allow you to read it, and if you have supervisor permissions on the server, to set and remove it. A summary of these tools is listed in Table 15.3. Table 15.3: Linux Bindery Manipulation Tools Command Name Command Description nwfstime Display or set a NetWare server’s date and time nwuserlist List users logged in at a NetWare server nwvolinfo Display info about NetWare volumes nwbocreate Create a NetWare bindery object nwbols List NetWare bindery objects nwboprops List properties of a NetWare bindery object nwborm Remove a NetWare bindery object nwbpcreate Create a NetWare bindery property

Hiding Your NetWare Login Password It is somewhat of a security risk to be putting a password on the command line, as we did with the ncpmount command. Other active, concurrent users could see the password if they happen to be running a program like topor ps. To reduce the risk of others seeing and stealing NetWare login passwords, ncpmount is able to read certain details from a file in a user’s home directory. In this file, the user keeps the login name and password associated with each of the fileservers he or she intends to mount. The file is called ~/.nwclient and it must have permissions of 0600 to ensure that others cannot read it. If the permissions are not correct, the ncpmount command will refuse to use it. The file has a very simple syntax. Any lines beginning with a # character are treated as comments and ignored. The remainder of the lines have the syntax: fileserver/userid password The fileserver is the name of the fileserver supporting the volumes you wish to mount. The userid is the login name of your account on that server. The password field is optional. If it is not supplied, the ncpmount command prompts users for the password when they attempt the mount. If the password field is specified as the character, no password is used; this is equivalent to the -n command-line argument. You can supply any number of entries, but the fileserver field must be unique. The first fileserver entry has special significance. The ncpmount command uses the -S command-line argument to determine which of the entries in ~/.nwclient to use. If no server is specified using the -S argument, the first server entry in ~/.nwclient is assumed, and is treated as your preferred server. You should place the fileserver you mount most frequently in the first position in the file. A More Complex ncpmount Example Let’s look at a more complex ncpmount example involving a number of the features we’ve described. First, let’s build a simple ~/.nwclient file: # NetWare login details for the Virtual Brewery and Winery # # Brewery Login ALES_F1/MATT staoic1 # # Winery Login REDS01/MATT staoic1 # Make sure its permissions are correct: $ chmod 600 ~/.nwclient Let’s mount one volume of the Winery’s server under a subdirectory of a shared directory, specifying the file and directory permissions such that others may share the data from there: $ ncpmount -S REDS01 -V RESEARCH -f 0664 -d 0775 /usr/share/winery/data/ This command, in combination with the ~/.nwclient file shown, would mount the RESEARCH volume of the REDS01 server onto the /usr/share/winery/data/ directory using the NetWare login ID of MATT and the password retrieved from the ~/.nwclient file. The permissions of the mounted files are 0664 and the directory permissions are 0775. Exploring Some of the Other IPX Tools The ncpfs package contains a number of useful tools that we haven’t described yet. Many of these tools emulate the tools that are supplied with NetWare. We’ll look at the most useful ones in this section. Server List The slist command lists all of the fileservers accessible to the host. The information is actually retrieved from the nearest IPX router. This command was probably originally intended to allow users to see what fileservers were available to mount. But it has become useful as a network diagnosis tool, allowing network admins to see where SAP information is being propagated:

Table 15.2: ncpmount Command Arguments Argument Description -S server The name of the fileserver to mount. -U user_ name The NetWare user ID to use when logging in to the fileserver. -P password The password to use for the NetWare login. -n This option must be used for NetWare logins that don’t have a password associated with them. -C This argument disables automatic conversion of passwords to uppercase. -c client_ name This option allows you to specify who owns the connection to the fileserver. This is useful for NetWare printing, which we will discuss in more detail later. -u uid The Linux user ID that should be shown as the owner of files in the mounted directory. If this is not specified, it defaults to the user ID of the user who invokes the ncpmount command. -g gid The Linux group ID that should be shown as the owner of files in the mounted directory. If this is not specified, it will default to the group ID of the user who invokes the ncpmount command. -f file_mode This option allows you to specify the file mode (permissions) that files in the mounted directory should have. The value should be specified in octal, e.g., 0664. The permissions that you will actually have are the file mode permissions specified with this option masked with the permissions that your NetWare login ID has for the files on the file- server. You must have rights on the server and rights specified by this option in order to access a file. The default value is derived from the current umask. -d dir_mode This option allows you to specify the directory permissions in the mounted directory. It behaves in the same way as the -f option, except that the default permissions are derived from the current umask. Execute permissions are granted where read access is granted. -V volume This option allows you to specify the name of a single NetWare volume to mount under the mount point, rather than mounting all volumes of the target server. This option is necessary if you wish to re-export a mounted NetWare volume using NFS. -t time_out This option allows you to specify the time that the NCPFS client will wait for a response from a server. The default value is 60mS and the timeout is specified in hundredths of a second. If you experience any stability problems with NCP mounts, you should try increasing this value. -r retry_ count The NCP client code attempts to resend datagrams to the server a number of times before deciding the connection is dead. This option allows you to change the retry count from the default of 5.

Mounting a Remote NetWare Volume IPX is commonly used to mount NetWare volumes in the Linux filesystem. This allows file-based data sharing between other operating systems and Linux. Volker Lendecke developed the NCP client for Linux and a suite of associated tools that make data sharing possible. In an NFS environment, we’d use the Linux mount command to mount the remote filesystem. Unfortunately, the NCP filesystem has unique requirements that make it impractical to build it into the normal mount. Linux has an ncpmount command that we will use instead. The ncpmount command is one of the tools in Volker’s ncpfs package, which is available prepackaged in most modern distributions or in source form from ftp.gwdg.de in the /pub/linux/misc/ncpfs/ directory. The version current at the time of writing is 2.2.0. Before you can mount remote NetWare volumes, you must ensure your IPX network interface is configured correctly (as described earlier). Next, you must know your login details on the NetWare server you wish to mount; this includes the user ID and password. Lastly, you need to know which volume you wish to mount and what local directory you wish to mount it under. A Simple ncpmount Example A simple example of ncpmount usage looks like this: # ncpmount -S ALES_F1 -U rick -P d00-b-gud /mnt/brewery This command mounts all volumes of the ALES_F1 fileserver under the /mnt/brewery directory, using the Net- Ware login rick with the password d00-b-gud. The ncpmount command is normally setuid to root and may therefore be used by any Linux user. By default, that user owns the connection and only he or the root user will be able to unmount it. NetWare embodies the notion of a volume, which is analogous to a filesystem in Linux. A NetWare volume is the logical representation of a NetWare filesystem, which might be a single disk partition be spread across many partitions. By default, the Linux NCPFS support treats volumes as subdirectories of a larger logical filesystem represented by the whole fileserver. The ncpmount command causes each of the NetWare volumes of the mounted fileserver to appear as a subdirectory under the mount point. This is convenient if you want access to the whole server, but for complex technical reasons you will be unable to re-export these directories using NFS, should you wish to do so. We’ll discuss a more complex alternative that works around this problem in a moment. The ncpmount Command in Detail The ncpmount has a large number of command line options that allow you quite a lot of flexibility in how you manage your NCP mounts. The most important of these are described in Table 15.2.

Figure 15.1: IPX internal network Allowing such hosts to have a virtual network with virtual host addresses that are entirely a software construct solves this problem. This virtual network is best thought of as being inside the IPX host. The SAP information then needs only to be propagated for this virtual network/node address combination. This virtual network is known as an internal network. But how do other hosts know how to reach this internal network? Remote hosts route to the internal network via the directly connected networks of the host. This means that you see routing entries that refer to the internal network of hosts supporting multiple IPX interfaces. Those routes should choose the optimal route available at the time, and should one fail, the routing is automatically updated to the next best interface and route. In Figure 15.1, we’ve configured an internal IPX network of address 0×10000010 and used a host address of 00:00:00:00:00:01. It is this address that will be our primary interface and will be advertised via SAP. Our routing will reflect this network as being reachable via either of our real network ports, so hosts will always use the best network route to connect to our server. To create this internal network, use the ipx_internal_net command included in Greg Page’s IPX tools package. Again, a simple example demonstrates its use: # ipx_internal_net add 10000010 000000000001 This command would create an IPX internal network with address 10000010 and a node address of 000000000001. The network address, just like any other IPX network address, must be unique on your network. The node address is completely arbitrary, as there will normally be only one node on the network. Each host may have only one IPX Internal Network, and if configured, the Internal Network will always be the primary network. To delete an IPX Internal Network, use: # ipx_internal_net del An internal IPX network is of absolutely no use to you unless your host both provides a service and has more than one IPX interface active.