Commit | Line | Data |
---|---|---|
38c57ffe WJ |
1 | Info file uucp.info, produced by Makeinfo, -*- Text -*- from input |
2 | file uucp.texi. | |
3 | ||
4 | This file documents Taylor UUCP, version 1.03. | |
5 | ||
6 | Copyright (C) 1992 Free Software Foundation, Inc. | |
7 | ||
8 | Permission is granted to make and distribute verbatim copies of this | |
9 | manual provided the copyright notice and this permission notice are | |
10 | preserved on all copies. | |
11 | ||
12 | Permission is granted to copy and distribute modified versions of | |
13 | this manual under the conditions for verbatim copying, provided also | |
14 | that the section entitled "Copying" are included exactly as in the | |
15 | original, and provided that the entire resulting derived work is | |
16 | distributed under the terms of a permission notice identical to this | |
17 | one. | |
18 | ||
19 | Permission is granted to copy and distribute translations of this | |
20 | manual into another language, under the above conditions for modified | |
21 | versions, except that the section entitled "Copying" may be included | |
22 | in a translation approved by the author instead of in the original | |
23 | English. | |
24 | ||
25 | \1f | |
26 | File: uucp.info, Node: Miscellaneous (sys), Next: Default sys File Values, Prev: File Transfer Control, Up: sys File | |
27 | ||
28 | Miscellaneous sys File Commands | |
29 | ------------------------------- | |
30 | ||
31 | `sequence BOOLEAN' | |
32 | If BOOLEAN is true, then conversation sequencing is automatically | |
33 | used for the remote system, so that if somebody manages to spoof | |
34 | as the remote system, it will be detected the next time the | |
35 | remote system actually calls. This is false by default. | |
36 | ||
37 | `command-path STRING' | |
38 | Specifies the path (a list of whitespace separated directories) | |
39 | to be searched to locate commands to execute. This is only used | |
40 | for commands requested by `uux', not for chat programs. The | |
41 | default is from `policy.h'. | |
42 | ||
43 | `commands STRINGS' | |
44 | The list of commands which the remote system is permitted to | |
45 | execute locally. For example: `commands rnews rmail'. If the | |
46 | value is `ALL' (case significant), all commands may be executed. | |
47 | The default is `rnews rmail'. | |
48 | ||
49 | `free-space NUMBER' | |
50 | Specify the minimum amount of file system space (in bytes) to | |
51 | leave free after receiving a file. If the incoming file will not | |
52 | fit, it will be rejected. This will only work when talking to | |
53 | another instance of this package, since older UUCP packages do | |
54 | not provide the file size of incoming files. There is no | |
55 | provision for reserving space, so it is still possible for | |
56 | multiple `uucico' daemons to use up all available file space; a | |
57 | sufficiently large value for `free-space' will avoid this problem | |
58 | to some extent. The default is from `policy.h'. Not all systems | |
59 | may be able to provide the amount of available space. | |
60 | ||
61 | `pubdir STRING' | |
62 | Specifies the public directory that is used when `~' is specifed | |
63 | in a file transfer or a list of directories. This essentially | |
64 | overrides the public directory specified in the main | |
65 | configuration file for this system only. The default is the | |
66 | public directory specified in the main configuration file (which | |
67 | defaults to a value from `policy.h'). | |
68 | ||
69 | `debug STRING ...' | |
70 | Set additional debugging for calls to or from the system. This | |
71 | may be used to debug a connection with a specific system. It is | |
72 | particularly useful when debugging incoming calls, since | |
73 | debugging information will be generated whenever the call comes | |
74 | in. See the `debug' command in the main configuration file | |
75 | (*note Debugging Levels::.) for more details. The debugging | |
76 | information specified here is in addition to that specified in | |
77 | the main configuration file or on the command line. | |
78 | ||
79 | `max-remote-debug STRING ...' | |
80 | When the system calls in, it may request that the debugging level | |
81 | be set to a certain value. This command may be used to put a | |
82 | limit on the debugging level which the system may request, to | |
83 | avoid filling up the disk with debugging information. Only the | |
84 | debugging types named in the `max-remote-debug' command may be | |
85 | turned on by the remote system. To prohibit any debugging, use | |
86 | `max-remote-debug none'. The default is | |
87 | `abnormal,chat,handshake'; to turn off these default entries, you | |
88 | must use `max-remote-debug none' followed by other | |
89 | `max-remote-debug' commands specifying the settings you want. | |
90 | ||
91 | `timetable STRING STRING' | |
92 | This is actually not specific to a system; it can appear anywhere | |
93 | in the file(s). In a future release this command will probably | |
94 | be moved to the main configuration file. | |
95 | ||
96 | The `timetable' defines a timetable that may be used in | |
97 | subsequently appearing time strings; *Note Time Strings::. The | |
98 | first string names the timetable entry; the second is a time | |
99 | string. | |
100 | ||
101 | The following `timetable' commands are predefined. The NonPeak | |
102 | timetable is included for compatibility. It originally described | |
103 | the offpeak hours of Tymnet and Telenet, but both have since | |
104 | changed their schedules. | |
105 | ||
106 | timetable Evening Wk1705-0755,Sa,Su | |
107 | timetable Night Wk2305-0755,Sa,Su2305-1655 | |
108 | timetable NonPeak Wk1805-0655,Sa,Su | |
109 | ||
110 | If this command does not appear, then obviously no additional | |
111 | timetables will be defined. | |
112 | ||
113 | \1f | |
114 | File: uucp.info, Node: Default sys File Values, Prev: Miscellaneous (sys), Up: sys File | |
115 | ||
116 | Default sys File Values | |
117 | ----------------------- | |
118 | ||
119 | The following are used as default values for all systems; they can | |
120 | be considered as appearing before the start of the file. | |
121 | ||
122 | timetable Evening Wk1705-0755,Sa,Su | |
123 | timetable Night Wk2305-0755,Sa,Su2305-1655 | |
124 | timetable NonPeak Wk1805-0655,Sa,Su | |
125 | time Never | |
126 | chat "" \r\c ogin:-BREAK-ogin:-BREAK-ogin: \L word: \P | |
127 | chat-timeout 10 | |
128 | callback n | |
129 | sequence n | |
130 | request y | |
131 | transfer y | |
132 | local-send / | |
133 | remote-send ~ | |
134 | local-receive ~ | |
135 | remove-receive ~ | |
136 | command-path [ from `policy.h' ] | |
137 | commands rnews rmail | |
138 | max-remote-debug abnormal,chat,handshake | |
139 | ||
140 | \1f | |
141 | File: uucp.info, Node: port File, Next: dial File, Prev: sys File, Up: Configuration Files | |
142 | ||
143 | The Port Configuration File | |
144 | =========================== | |
145 | ||
146 | The port files may be used to name and describe ports. The first | |
147 | command in each file must be `port'. All command up to the next | |
148 | `port' command then describe that port. There are different types of | |
149 | ports; each type supports its own set of commands. Each command | |
150 | indicates which types of ports support it. There may be many ports | |
151 | with the same name; if a system requests a port by name then each port | |
152 | with that name will be tried until an unlocked one is found. | |
153 | ||
154 | `port STRING' | |
155 | Introduces and names a port. | |
156 | ||
157 | `type STRING' | |
158 | Define the type of port. The default is `modem'. If this command | |
159 | appears, it must immediately follow the `port' command. The type | |
160 | defines what commands are subsequently allowed. Currently the | |
161 | types are: | |
162 | ||
163 | `modem' | |
164 | For a modem hookup. | |
165 | ||
166 | `stdin' | |
167 | For a connection through standard input and standard output, | |
168 | as when `uucico' is run as a login shell. | |
169 | ||
170 | `direct' | |
171 | For a direct connection to another system. | |
172 | ||
173 | `tcp' | |
174 | For a connection using TCP. | |
175 | ||
176 | `protocol STRING' | |
177 | Specify a list of protocols to use for this port. This is just | |
178 | like the corresponding command for a system (*note Protocol | |
179 | Selection::.). A protocol list for a system takes precedence | |
180 | over a list for a port. | |
181 | ||
182 | `protocol-parameter CHARACTER STRINGS [ any type ]' | |
183 | The same command as the `protocol-parameter' command used for | |
184 | systems (*note Protocol Selection::.). This one takes precedence. | |
185 | ||
186 | `seven-bit BOOLEAN [ any type ]' | |
187 | This is only used during protocol negotiation; if the argument is | |
188 | `true', it forces the selection of a protocol which works across a | |
189 | seven-bit link. It does not prevent eight bit characters from | |
190 | being transmitted. The default is `false'. | |
191 | ||
192 | `reliable BOOLEAN [ any type ]' | |
193 | This is only used during protocol negotiation; if the argument is | |
194 | `false', it forces the selection of a protocol which works across | |
195 | an unreliable communication link. The default is `true'. It | |
196 | would be more common to specify this for a dialer rather than a | |
197 | port. | |
198 | ||
199 | `device STRING [ modem and direct only ]' | |
200 | Names the device associated with this port. If the device is not | |
201 | named, the port name is taken as the device. Device names are | |
202 | system dependent, but a Unix example would be `/dev/ttyd0'. | |
203 | ||
204 | `baud NUMBER [ modem and direct only ]' | |
205 | `speed NUMBER [modem and direct only ]' | |
206 | The speed this port runs at. If a system specifies a speed but | |
207 | no port name, then all ports which match the speed will be tried | |
208 | in order. If the speed is not specified here and is not | |
209 | specified by the system, the natural speed of the port will be | |
210 | used by default. | |
211 | ||
212 | `baud-range NUMBER NUMBER [ modem only ]' | |
213 | `speed-range NUMBER NUMBER [ modem only ]' | |
214 | Specify a range of speeds this port can run at. The first number | |
215 | is the minimum speed, the second number is the maximum speed. | |
216 | These numbers will be used when matching a system which specifies | |
217 | a desired speed. The simple `speed' (or `baud') command is still | |
218 | used to determine the speed to run at if the system does not | |
219 | specify a speed. For example, the command `speed-range 300 | |
220 | 19200' means that the port will match any system which uses a | |
221 | speed from 300 to 19200 baud (and will use the speed specified by | |
222 | the system); this could be combined with `speed 2400', which | |
223 | means that when this port is used with a system that does not | |
224 | specify a speed, the port will be used at 2400 baud. | |
225 | ||
226 | `carrier BOOLEAN [ modem only ]' | |
227 | The argument indicates whether the port supports carrier. If it | |
228 | does not, carrier will never be required on this port, regardless | |
229 | of what the modem chat script indicates. The default is `true'. | |
230 | ||
231 | `dial-device STRING [ modem only ]' | |
232 | Dialing instructions should be output to the named device, rather | |
233 | than to the normal port device. The default is to output to the | |
234 | normal port device. | |
235 | ||
236 | `dialer STRING [ modem only ]' | |
237 | Name a dialer to use. The information is looked up in the dialer | |
238 | file. There is no default. Some sort of dialer information must | |
239 | be specified to call out on a modem. | |
240 | ||
241 | `dialer STRING ... [ modem only ]' | |
242 | Execute a dialer command. If a dialer is named (by using the | |
243 | first form of this command, described just above), these commands | |
244 | are ignored. They may be used to specify dialer information | |
245 | directly in simple situations without needing to go to a separate | |
246 | file. There is no default. Some sort of dialer information must | |
247 | be specified to call out on a modem. | |
248 | ||
249 | `dialer-sequence STRINGS [ modem only ]' | |
250 | Name a sequence of dialers and tokens (phone numbers) to use. | |
251 | The first argument names a dialer, and the second argument names | |
252 | a token. The third argument names another dialer, and so on. If | |
253 | there are an odd number of arguments, the phone number specified | |
254 | with a `phone' command in the system file is used as the final | |
255 | token. The token is what is used for `\D' or `\T' in the dialer | |
256 | chat script. If the token in this string is `\D', the system | |
257 | phone number will be used; if it is `\T', the system phone number | |
258 | will be used after undergoing dialcodes translation. A missing | |
259 | final token is taken as `\D'. | |
260 | ||
261 | This command currently does not work if `dial-device' is | |
262 | specified; to handle this correctly will require a more | |
263 | systematic notion of chat scripts. Moreover, only the `complete' | |
264 | and `abort' chat scripts from the first dialer specified are | |
265 | used, and only the protocol parameters from the first dialer are | |
266 | used. | |
267 | ||
268 | `lockname STRING [ modem and direct only ]' | |
269 | Give the name to use when locking this port. On Unix, this is | |
270 | the name of the file that will be created in the lock directory. | |
271 | It is used as is, so on Unix it should generally start with | |
272 | `LCK..'. For example, if a single port were named both | |
273 | `/dev/ttycu0' and `/dev/tty0' (perhaps with different | |
274 | characteristics keyed on the minor device number), then the | |
275 | command `lockname LCK..ttycu0' could be used to force the latter | |
276 | to use the same lock file name as the former. | |
277 | ||
278 | `service STRING [ tcp only ]' | |
279 | Name the TCP port number to use. This may be a number. If not, | |
280 | it will be looked up in `/etc/services'. If this is not | |
281 | specified, the string `uucp' is looked up in `/etc/services'. If | |
282 | it is not found, port number 540 (the standard UUCP-over-TCP port | |
283 | number) will be used. | |
284 | ||
285 | \1f | |
286 | File: uucp.info, Node: dial File, Next: Security, Prev: port File, Up: Configuration Files | |
287 | ||
288 | The Dialer Configuration File | |
289 | ============================= | |
290 | ||
291 | The dialer configuration files define dialers. The first command in | |
292 | each file must be a `dialer' command, which names the dialer. | |
293 | Subsequent commands up to the next `dialer' command are associated | |
294 | with the named dialer. | |
295 | ||
296 | `dialer STRING' | |
297 | Introduces and names a dialer. | |
298 | ||
299 | `chat STRINGS' | |
300 | `chat-timeout NUMBER' | |
301 | `chat-fail STRING' | |
302 | `chat-seven-bit BOOLEAN' | |
303 | `chat-program STRINGS' | |
304 | Specify a chat script to be used to dial the phone. See *Note | |
305 | Chat Scripts:: for full details on chat scripts. | |
306 | ||
307 | Taylor UUCP will sleep for one second between attempts to dial | |
308 | out on a modem. If your modem requires a longer wait period, you | |
309 | must start your chat script with delays (`\d' in a send string). | |
310 | ||
311 | The chat script will be read from and sent to the port specified | |
312 | by the `dial-device' command for the port, if there is one. | |
313 | ||
314 | The following escape addition escape sequences may appear in send | |
315 | strings: | |
316 | ||
317 | `\D' | |
318 | send phone number without dialcode translation | |
319 | ||
320 | `\T' | |
321 | send phone number with dialcode translation | |
322 | ||
323 | `\M' | |
324 | do not require carrier | |
325 | ||
326 | `\m' | |
327 | require carrier (fail if not present) | |
328 | ||
329 | See the description of the dialcodes file (*note Configuration | |
330 | File Names::.) for a description of dialcode translation. If the | |
331 | port does not support carrier (as set by the `carrier' command in | |
332 | the port file) `\M' and `\m' are ignored. If both the port and | |
333 | the dialer support carrier (as set by the `carrier' command in | |
334 | the port file and the `carrier' command in the dialer file), then | |
335 | every chat script implicitly begins with `\M' and ends with `\m'. | |
336 | There is no default chat script for dialers. | |
337 | ||
338 | The following additional escape sequences may be used in | |
339 | `chat-program': | |
340 | ||
341 | `\D' | |
342 | phone number without dialcode translation | |
343 | ||
344 | `\T' | |
345 | phone number with dialcode translation | |
346 | ||
347 | If the program changes the port in any way (e.g., sets parity) the | |
348 | changes will be preserved during protocol negotiation, but once | |
349 | the protocol is selected it will change the port settings. | |
350 | ||
351 | `dialtone STRING' | |
352 | A string to output when dialing the phone number which causes the | |
353 | modem to wait for a secondary dial tone. This is used to | |
354 | translate the `=' character in a phone number. The default is a | |
355 | comma. | |
356 | ||
357 | `pause STRING' | |
358 | A string to output when dialing the phone number which causes the | |
359 | modem to wait for 1 second. This is used to translate the `-' | |
360 | character in a phone number. The default is a comma. | |
361 | ||
362 | `carrier BOOLEAN' | |
363 | If the argument is `true', the dialer supports the modem carrier | |
364 | signal. After the phone number is dialed, `uucico' will require | |
365 | that carrier be on. One some systems, it will be able to wait | |
366 | for it. If the argument is `false', carrier will not be | |
367 | required. The default is `true'. | |
368 | ||
369 | `carrier-wait NUMBER' | |
370 | If the port is supposed to wait for carrier, this may be used to | |
371 | indicate how many seconds to wait. The default is 60 seconds. | |
372 | Only some systems support waiting for carrier. | |
373 | ||
374 | `dtr-toggle BOOLEAN BOOLEAN' | |
375 | If the first argument is `true', then DTR is toggled before using | |
376 | the modem. This is only supported on some systems and some | |
377 | ports. The second BOOLEAN need not be present; if it is, and it | |
378 | is `true', the program will sleep for 1 second after toggling DTR. | |
379 | The default is not to toggle DTR. | |
380 | ||
381 | `complete-chat STRINGS' | |
382 | `complete-chat-timeout NUMBER' | |
383 | `complete-chat-fail STRING' | |
384 | `complete-chat-seven-bit BOOLEAN' | |
385 | `complete-chat-program STRINGS' | |
386 | These commands define a chat script (*note Chat Scripts::.) which | |
387 | is run when a call is finished normally. This allows the modem | |
388 | to be reset. There is no default. No additional escape | |
389 | sequences may be used. | |
390 | ||
391 | `complete STRING' | |
392 | This is a simple use of `complete-chat'. It is equivalent to | |
393 | `complete-chat "" STRING'; this has the effect of sending STRING | |
394 | to the modem when a call finishes normally. | |
395 | ||
396 | `abort-chat STRINGS' | |
397 | `abort-chat-timeout NUMBER' | |
398 | `abort-chat-fail STRING' | |
399 | `abort-chat-seven-bit BOOLEAN' | |
400 | `abort-chat-program STRINGS' | |
401 | These commands define a chat script (*note Chat Scripts::.) to be | |
402 | run when a call is aborted. They may be used to interrupt and | |
403 | reset the modem. There is no default. No additional escape | |
404 | sequences may be used. | |
405 | ||
406 | `abort STRING' | |
407 | This is a simple use of `abort-chat'. It is equivalent to | |
408 | `abort-chat "" STRING'; this has the effect of sending STRING to | |
409 | the modem when a call is aborted. | |
410 | ||
411 | `protocol-parameter CHARACTER STRINGS' | |
412 | Set protocol parameters, just like the `protocol-parameter' | |
413 | command in the system configuration file or the port | |
414 | configuration file; see *Note Protocol Selection::. These | |
415 | parameters take precedence, then those for the port, then those | |
416 | for the system. | |
417 | ||
418 | `seven-bit BOOLEAN' | |
419 | This is only used during protocol negotiation; if it is `true', it | |
420 | forces selection of a protocol which works across a seven-bit | |
421 | link. It does not prevent eight bit characters from being | |
422 | transmitted. The default is `false'. It would be more common to | |
423 | specify this for a port than for a dialer. | |
424 | ||
425 | `reliable BOOLEAN' | |
426 | This is only used during protocol negotiation; if it is `false', | |
427 | it forces selection of a protocol which works across an unreliable | |
428 | communication link. The default is `true'. | |
429 | ||
430 | \1f | |
431 | File: uucp.info, Node: Security, Prev: dial File, Up: Configuration Files | |
432 | ||
433 | Security | |
434 | ======== | |
435 | ||
436 | This discussion of UUCP security applies only to Unix. It is a bit | |
437 | cursory; suggestions for improvement are solicited. | |
438 | ||
439 | UUCP is traditionally not very secure. Taylor UUCP addresses some | |
440 | security issues, but is still far from being a secure system. | |
441 | ||
442 | If security is very important to you, then you should not permit any | |
443 | external access to your computer, including UUCP. Any opening to the | |
444 | outside world is a potential security risk. | |
445 | ||
446 | By default Taylor UUCP provides few mechanisms to secure local | |
447 | users of the system from each other. You can allow increased security | |
448 | by putting the owner of the UUCP programs (normally `uucp') into a | |
449 | separate group; the use of this is explained in the following | |
450 | paragraphs, which refer to this separate group as `uucp-group'. | |
451 | ||
452 | When the `uucp' program is invoked to copy a file to a remote | |
453 | system, it will by default copy the file into the UUCP spool directory. | |
454 | When the `uux' program is used, the `-C' switch must be used to copy | |
455 | the file into the UUCP spool directory. In any case, once the file | |
456 | has been copied into the spool directory, other local users will not | |
457 | be able to access it. In version 1.03 there is a security hole in | |
458 | that for the file to be copied it must be readable by `uucp'. | |
459 | Changing the group of the file to `uucp-group' and making it group | |
460 | readable will permit UUCP to read it without granting access to other | |
461 | users. | |
462 | ||
463 | When a file is requested from a remote system, UUCP will only | |
464 | permit it to be placed in a directory which is writable by the | |
465 | requesting user. The directory must also be writable by UUCP. A | |
466 | local user can create a directory with a group of `uucp-group' and set | |
467 | the mode to permit group write access. This will allow the file be | |
468 | requested without permitting it to be viewed by any other user. | |
469 | ||
470 | There is no provision for security for `uucp' requests (as opposed | |
471 | to `uux' requests) made by a user on a remote system. A file sent | |
472 | over by a remote request may only be placed in a directory which is | |
473 | world writable, and the file will be world readable and writable. This | |
474 | will permit any local user to destroy or replace the contents of the | |
475 | file. A file requested by a remote system must be world readable, and | |
476 | the directory it is in must be world readable. Any local user will be | |
477 | able to examine, although not necessarily modify, the file before it is | |
478 | sent. | |
479 | ||
480 | There are some security holes and race conditions that apply to the | |
481 | above discussion which I will not elaborate on. They are not hidden | |
482 | from anybody who reads the source code, but they are somewhat technical | |
483 | and difficult (but scarcely impossible) to exploit. Suffice it to say | |
484 | that even under the best of conditions UUCP is not completely secure. | |
485 | ||
486 | For many sites, security from remote sites is a more important | |
487 | consideration. Fortunately, Taylor UUCP does provide some support in | |
488 | this area. | |
489 | ||
490 | The greatest security is provided by always dialing out to the other | |
491 | site. This prevents anybody from pretending to be the other site. Of | |
492 | course, only one side of the connection can do this. | |
493 | ||
494 | If remote dialins must be permitted, then it is best if the dialin | |
495 | line is used only for UUCP. If this is the case, then you should | |
496 | create a call-in password file (*note Configuration File Names::.) and | |
497 | let `uucico' do its own login prompting. For example, to let remote | |
498 | sites log in on a port named `entry' in the port file (*note port | |
499 | file::.) you might invoke `uucico -p entry'. This would cause | |
500 | `uucico' to enter an endless loop of login prompts and daemon | |
501 | executions. The advantage of this approach is that even if remote | |
502 | users break into the system by guessing or learning the password, they | |
503 | will only be able to do whatever `uucico' permits them to do. They | |
504 | will not be able to start a shell on your system. | |
505 | ||
506 | If remote users can dial in and log on to your system, then you | |
507 | have a security hazard more serious than that posed by UUCP. But | |
508 | then, you probably knew that already. | |
509 | ||
510 | Once your system has connected with the remote UUCP, there is a fair | |
511 | amount of control you can exercise. You can use the `remote-send' and | |
512 | `remote-receive' commands to control the directories the remote UUCP | |
513 | can access. You can use the `request' command to prevent the remote | |
514 | UUCP from making any requests of your system at all; however, if you | |
515 | do this it will not even be able to send you mail or news. If you do | |
516 | permit remote requests, you should be careful to restrict what | |
517 | commands may be executed at the remote system's request. The default | |
518 | is `rmail' and `rnews', which will suffice for most systems. | |
519 | ||
520 | If different remote systems call in and they must be granted | |
521 | different privileges (perhaps some systems are within the same | |
522 | organization and some are not) then the `called-login' command should | |
523 | be used for each system to require that they different login names. | |
524 | Otherwise it would be simple for a remote system to use the `myname' | |
525 | command and pretend to be a different system. The `sequence' command | |
526 | can be used to detect when one system pretended to be another, but | |
527 | since the sequence numbers must be reset manually after a failed | |
528 | handshake this can sometimes be more trouble than it's worth. | |
529 | ||
530 | \1f | |
531 | File: uucp.info, Node: Protocols, Next: Hacking, Prev: Configuration Files, Up: Top | |
532 | ||
533 | UUCP protocol internals | |
534 | *********************** | |
535 | ||
536 | This chapter describes how the various UUCP protocols work, and | |
537 | discusses some other internal UUCP issues. | |
538 | ||
539 | This chapter is quite technical. You do not need to understand it, | |
540 | or even read it, in order to use Taylor UUCP. It is intended for | |
541 | people who are interested in how UUCP code works. | |
542 | ||
543 | Most of the discussion covers the protocols used by all UUCP | |
544 | packages, not just Taylor UUCP. Any information specific to Taylor | |
545 | UUCP is indicated as such. There are some pointers to the actual | |
546 | functions in the Taylor UUCP source code, for those who are extremely | |
547 | interested in actual UUCP implementation. | |
548 | ||
549 | * Menu: | |
550 | ||
551 | * Grades:: UUCP grades | |
552 | * Lock Files:: UUCP lock file format | |
553 | * UUCP Protocol:: The common UUCP protocol | |
554 | * g Protocol:: The UUCP `g' protocol | |
555 | * f Protocol:: The UUCP `f' protocol | |
556 | * t Protocol:: The UUCP `t' protocol | |
557 | * e Protocol:: The UUCP `e' protocol | |
558 | * x Protocol:: The UUCP `x' protocol | |
559 | * d Protocol:: The UUCP `d' protocol | |
560 | * Capital G Protocol:: The UUCP `G' protocol | |
561 | * Documentation References:: Documentation references | |
562 | ||
563 | \1f | |
564 | File: uucp.info, Node: Grades, Next: Lock Files, Prev: Protocols, Up: Protocols | |
565 | ||
566 | UUCP Grades | |
567 | =========== | |
568 | ||
569 | Modern UUCP packages support grades for each command. The grades | |
570 | generally range from `A' (the highest) to `Z' followed by `a' to `z'. | |
571 | Taylor UUCP also supports `0' to `9' before `A'. Some UUCP packages | |
572 | may permit any ASCII character as a grade. | |
573 | ||
574 | On Unix, these grades are encoded in the name of the command file. | |
575 | A command file name generally has the form | |
576 | ||
577 | C.nnnngssss | |
578 | ||
579 | where NNNN is the remote system name for which the command is queued, | |
580 | G is a single character grade, and SSSS is a four character sequence | |
581 | number. For example, a command file created for the system `airs' at | |
582 | grade `Z' might be named | |
583 | ||
584 | C.airsZ2551 | |
585 | ||
586 | The remote system name will be truncated to seven characters, to | |
587 | ensure that the command file name will fit in the 14 character file | |
588 | name limit of the traditional Unix file system. UUCP packages which | |
589 | have no other means of distinguishing which command files are intended | |
590 | for which systems thus require all *systems they connect to* to have | |
591 | names that are unique in the first seven characters. Some UUCP | |
592 | packages use a variant of this format which truncates the system name | |
593 | to six characters. BNU uses a different spool directory format, which | |
594 | allows up to fourteen characters to be used for each system name. The | |
595 | Taylor UUCP spool directory format is configurable. The new Taylor | |
596 | spool directory format permits system names to be as long as file | |
597 | names; the maximum length of a file name depends on the particular | |
598 | Unix file system being used. | |
599 | ||
600 | The sequence number in the command file name may be a decimal | |
601 | integer, or it may be a hexadecimal integer, or it may contain any | |
602 | alphanumeric character. Different UUCP packages are different. | |
603 | ||
604 | Taylor UUCP creates command files in the function | |
605 | `zsysdep_spool_commands'. The file name is constructed by the | |
606 | function `zsfile_name', which knows about all the different types of | |
607 | spool directories supported by Taylor UUCP. The Taylor UUCP sequence | |
608 | number can contain any alphanumeric character; the next sequence number | |
609 | is determined by the function `fscmd_seq'. | |
610 | ||
611 | I do not know how command grades are handled in non-Unix UUCP | |
612 | packages. | |
613 | ||
614 | Modern UUCP packages allow you to restrict file transfer by grade | |
615 | depending on the time of day. Typically this is done with a line in | |
616 | the `Systems' (or `L.sys') file like this: | |
617 | ||
618 | airs Any/Z,Any2305-0855 ... | |
619 | ||
620 | This allows only grades `Z' and above to be transferred at any | |
621 | time. Lower grades may only be transferred at night. I believe that | |
622 | this grade restriction applies to local commands as well as to remote | |
623 | commands, but I am not sure. It may only apply if the UUCP package | |
624 | places the call, not if it is called by the remote system. Taylor UUCP | |
625 | can use the `timegrade' and `call-timegrade' commands (*note When to | |
626 | Call::.) to achieve the same effect (and supports the above format | |
627 | when reading `Systems' or `L.sys'). | |
628 | ||
629 | This sort of grade restriction is most useful if you know what | |
630 | grades are being used at the remote site. The default grades used | |
631 | depend on the UUCP package. Generally `uucp' and `uux' have different | |
632 | defaults. A particular grade can be specified with the `-g' option to | |
633 | `uucp' or `uux'. For example, to request execution of rnews on airs | |
634 | with grade `d', you might use something like | |
635 | ||
636 | uux -gd - airs!rnews <article | |
637 | ||
638 | `uunet' queues up mail at grade `Z' and news at grade `d'. The | |
639 | example above would allow mail to be received at any time, but would | |
640 | only permit news to be transferred at night. | |
641 | ||
642 | \1f | |
643 | File: uucp.info, Node: Lock Files, Next: UUCP Protocol, Prev: Grades, Up: Protocols | |
644 | ||
645 | UUCP Lock File Format | |
646 | ===================== | |
647 | ||
648 | This discussion applies only to Unix. I have no idea how UUCP locks | |
649 | ports on other systems. | |
650 | ||
651 | UUCP creates files to lock serial ports and systems. On most (if | |
652 | not all) systems, these same lock files are also used by cu to | |
653 | coordinate access to serial ports. On some systems getty also uses | |
654 | these lock files. | |
655 | ||
656 | The lock file normally contains the process ID of the locking | |
657 | process. This makes it easy to determine whether a lock is still | |
658 | valid. The algorithm is to create a temporary file and then link it | |
659 | to the name that must be locked. If the link fails because a file | |
660 | with that name already exists, the existing file is read to get the | |
661 | process ID. If the process still exists, the lock attempt fails. | |
662 | Otherwise the lock file is deleted and the locking algorithm is | |
663 | retried. | |
664 | ||
665 | Older UUCP packages put the lock files in the main UUCP spool | |
666 | directory, /usr/spool/uucp. BNU UUCP generally puts the lock files in | |
667 | a directory of their own, usually /usr/spool/locks or /etc/locks. | |
668 | ||
669 | The original UUCP lock file format encoded the process ID as a four | |
670 | byte binary number. The order of the bytes was host-dependent. BNU | |
671 | UUCP stores the process ID as a ten byte ASCII decimal number, with a | |
672 | trailing newline. For example, if process 1570 holds a lock file, it | |
673 | would contain the eleven characters space, space, space, space, space, | |
674 | space, one, five, seven, zero, newline. Some versions of UUCP add a | |
675 | second line indicating which program created the lock (uucp, cu, or | |
676 | getty). I have also seen a third type of UUCP lock file which did not | |
677 | contain the process ID at all. | |
678 | ||
679 | The name of the lock file is generally "LCK.." followed by the base | |
680 | name of the device. For example, to lock /dev/ttyd0 the file | |
681 | LCK..ttyd0 would be created. There are various exceptions. On SCO | |
682 | Unix, the lock file name is always forced to lower case even if the | |
683 | device name has upper case letters. System V Release 4 UUCP forms the | |
684 | lock file name using the major and minor device numbers rather than | |
685 | the device name (this is pretty sensible if you think about it). | |
686 | ||
687 | Taylor UUCP can be configured to use various different types of | |
688 | locking. The actual locking code is in the function `fsdo_lock'. | |
689 | ||
690 | \1f | |
691 | File: uucp.info, Node: UUCP Protocol, Next: g Protocol, Prev: Lock Files, Up: Protocols | |
692 | ||
693 | The Common UUCP Protocol | |
694 | ======================== | |
695 | ||
696 | The UUCP protocol is a conversation between two UUCP packages. A | |
697 | UUCP conversation consists of three parts: an initial handshake, a | |
698 | series of file transfer requests, and a final handshake. | |
699 | ||
700 | Before the initial handshake, the caller will usually have logged | |
701 | in the called machine and somehow started the UUCP package there. On | |
702 | Unix this is normally done by setting the shell of the login name used | |
703 | to `uucico'. | |
704 | ||
705 | * Menu: | |
706 | ||
707 | * Initial Handshake:: Initial handshake | |
708 | * File Requests:: File requests | |
709 | * Final Handshake:: Final handshake | |
710 | ||
711 | \1f | |
712 | File: uucp.info, Node: Initial Handshake, Next: File Requests, Prev: UUCP Protocol, Up: UUCP Protocol | |
713 | ||
714 | Initial Handshake | |
715 | ----------------- | |
716 | ||
717 | All messages in the initial handshake begin with a `^P' (a byte | |
718 | with the octal value \020) and end with a null byte (\000). | |
719 | ||
720 | Taylor UUCP implements the initial handshake for the calling | |
721 | machine in `fdo_call', and for the called machine in `faccept_call'. | |
722 | ||
723 | The initial handshake goes as follows. It is begun by the called | |
724 | machine. | |
725 | ||
726 | called: `\020Shere=HOSTNAME\000' | |
727 | The HOSTNAME is the UUCP name of the called machine. Older UUCP | |
728 | packages do not output it, and simply send `\020Shere\000'. | |
729 | ||
730 | caller: `\020SHOSTNAME OPTIONS\000' | |
731 | The HOSTNAME is the UUCP name of the calling machine. The | |
732 | following OPTIONS may appear (or there may be none): | |
733 | ||
734 | `-QSEQ' | |
735 | Report sequence number for this conversation. The sequence | |
736 | number is stored at both sites, and incremented after each | |
737 | call. If there is a sequence number mismatch, something has | |
738 | gone wrong (somebody may have broken security by pretending | |
739 | to be one of the machines) and the call is denied. If the | |
740 | sequence number changes on one of the machines, perhaps | |
741 | because of an attempted breakin or because a disk backup was | |
742 | restored, the sequence numbers on the two machines must be | |
743 | reconciled manually. | |
744 | ||
745 | `-xLEVEL' | |
746 | Requests the called system to set its debugging level to the | |
747 | specified value. This is not supported by all systems. | |
748 | Taylor UUCP currently never generates this switch. When it | |
749 | sees it, it restricts the value according to | |
750 | `max-remote-debug' (*note Miscellaneous (sys)::.). | |
751 | ||
752 | `-pGRADE' | |
753 | `-vgrade=GRADE' | |
754 | Requests the called system to only transfer files of the | |
755 | specified grade or higher. This is not supported by all | |
756 | systems. Some systems support `-p', some support | |
757 | `-vgrade='. Taylor UUCP supports both. | |
758 | ||
759 | `-R' | |
760 | Indicates that the calling UUCP understands how to restart | |
761 | failed file transmissions. Supported only by System V | |
762 | Release 4 UUCP. | |
763 | ||
764 | `-ULIMIT' | |
765 | Reports the `ulimit' value of the calling UUCP. The limit is | |
766 | specified as a base 16 number in C notation (e.g., | |
767 | `-U0x1000000'). This number is the number of 512 byte | |
768 | blocks in the largest file which the calling UUCP can | |
769 | create. The called UUCP may not transfer a file larger than | |
770 | this. Supported by System V Release 4 UUCP. Taylor UUCP | |
771 | understands this option, but never generates it. | |
772 | ||
773 | `-N' | |
774 | Indicates that the calling UUCP understands the Taylor UUCP | |
775 | size limiting extensions. Supported only by Taylor UUCP. | |
776 | ||
777 | called: `\020ROK\000' | |
778 | There are actually several possible responses. | |
779 | ||
780 | `ROK' | |
781 | The calling UUCP is acceptable, and the handshake proceeds | |
782 | to the protocol negotiation. Some options may also appear; | |
783 | see below. | |
784 | ||
785 | `ROKN' | |
786 | The calling UUCP is acceptable, it specified `-N', and the | |
787 | called UUCP also understands the Taylor UUCP size limiting | |
788 | extensions. Supported only by Taylor UUCP. | |
789 | ||
790 | `RLCK' | |
791 | The called UUCP already has a lock for the calling UUCP, | |
792 | which normally indicates the two machines are already | |
793 | communicating. | |
794 | ||
795 | `RCB' | |
796 | The called UUCP will call back. This may be used to avoid | |
797 | impostors. Note that only one machine out of each pair | |
798 | should call back, or no conversation will ever begin. | |
799 | ||
800 | `RBADSEQ' | |
801 | The call sequence number is wrong (see the `-Q' discussion | |
802 | above). | |
803 | ||
804 | `RLOGIN' | |
805 | The calling UUCP is using the wrong login name. | |
806 | ||
807 | `RYou are unknown to me' | |
808 | The calling UUCP is not known to the called UUCP, and the | |
809 | called UUCP does not permit connections from unknown systems. | |
810 | ||
811 | If the response is `ROK', the following options are supported by | |
812 | System V Release 4 UUCP. | |
813 | ||
814 | `-R' | |
815 | The called UUCP knows how to restart failed file | |
816 | transmissions. | |
817 | ||
818 | `-ULIMIT' | |
819 | Reports the ulimit value of the called UUCP. The limit is | |
820 | specified as a base 16 number in C notation. This number is | |
821 | the number of 512 byte blocks in the largest file which the | |
822 | called UUCP can create. The calling UUCP may not send a | |
823 | file larger than this. | |
824 | ||
825 | `-xLEVEL' | |
826 | I'm told that this is sometimes sent by SVR4 UUCP, but I'm | |
827 | not sure exactly what it means. It may request the calling | |
828 | UUCP to set its debugging level to the specified value. | |
829 | ||
830 | If the response is not `ROK' (or `ROKN') both sides hang up the | |
831 | phone, abandoning the call. | |
832 | ||
833 | called: `\020PPROTOCOLS\000' | |
834 | The `P' is a literal character. Note that the called UUCP outputs | |
835 | two strings in a row. The PROTOCOLS string is a list of UUCP | |
836 | protocols supported by the caller. Each UUCP protocol has a | |
837 | single character name. For example, the called UUCP might send | |
838 | `\020Pgf\000'. | |
839 | ||
840 | caller: `\020UPROTOCOL\000' | |
841 | The `U' is a literal character. The calling UUCP selects which | |
842 | PROTOCOL to use out of the protocols offered by the called UUCP. | |
843 | If there are no mutually supported protocols, the calling UUCP | |
844 | sends `\020UN\000' and both sides hang up the phone. Otherwise | |
845 | the calling UUCP sends something like `\020Ug\000'. | |
846 | ||
847 | Most UUCP packages will consider each locally supported protocol in | |
848 | turn and select the first one supported by the called UUCP. With some | |
849 | versions of BNU UUCP, this can be modified by giving a list of | |
850 | protocols after the device name in the Devices file or the `Systems' | |
851 | file. Taylor UUCP provides the `protocol' command which may be used | |
852 | either for a system (*note Protocol Selection::.) or a port (*note | |
853 | port file::.). | |
854 | ||
855 | After the protocol has been selected and the initial handshake has | |
856 | been completed, both sides turn on the selected protocol. For some | |
857 | protocols (notably `g') a further handshake is done at this point. | |
858 | ||
859 | Each protocol supports a method for sending a command to the remote | |
860 | system. This method is used to transmit a series of commands between | |
861 | the two UUCP packages. At all times, one package is the master and the | |
862 | other is the slave. Initially, the calling UUCP is the master. | |
863 | ||
864 | If a protocol error occurs during the exchange of commands, both | |
865 | sides move immediately to the final handshake. | |
866 | ||
867 | \1f | |
868 | File: uucp.info, Node: File Requests, Next: Final Handshake, Prev: Initial Handshake, Up: UUCP Protocol | |
869 | ||
870 | File Requests | |
871 | ------------- | |
872 | ||
873 | The master will send one of four commands: `S', `R', `X' or `H'. | |
874 | ||
875 | Any file name referred to below is either an absolute pathname | |
876 | beginning with `/', a public directory pathname beginning with `~/', a | |
877 | pathname relative to a user's home directory beginning with `~USER/', | |
878 | or a spool directory file name. File names in the spool directory are | |
879 | not pathnames, but instead are converted to pathnames within the spool | |
880 | directory by UUCP. They always begin with `C.' (for a command file | |
881 | created by `uucp' or `uux'), `D.' (for a data file created by `uucp', | |
882 | `uux' or by an execution, or received from another system for an | |
883 | execution), or `X.' (for an execution file created by `uux' or | |
884 | received from another system). | |
885 | ||
886 | Taylor UUCP chooses which request to send next in the function | |
887 | `fuucp'. This is also where Taylor UUCP processes incoming commands | |
888 | from the remote system. | |
889 | ||
890 | * Menu: | |
891 | ||
892 | * S Request:: S request | |
893 | * R Request:: R request | |
894 | * X Request:: X request | |
895 | * H Request:: H request | |
896 | ||
897 | \1f | |
898 | File: uucp.info, Node: S Request, Next: R Request, Prev: File Requests, Up: File Requests | |
899 | ||
900 | S Request | |
901 | ......... | |
902 | ||
903 | master: `S FROM TO USER -OPTIONS TEMP MODE NOTIFY SIZE' | |
904 | ||
905 | The `S' and the `-' are literal characters. This is a request by | |
906 | the master to send a file to the slave. Taylor UUCP handles the `S' | |
907 | request in the function `fsend_file'. | |
908 | ||
909 | FROM | |
910 | The name of the file to send. If the `C' option does not appear | |
911 | in OPTIONS, the master will actually open and send this file. | |
912 | Otherwise the file has been copied to the spool directory, where | |
913 | it is named TEMP. The slave ignores this field unless TO is a | |
914 | directory, in which case the basename of FROM will be used as the | |
915 | file name. If FROM is a spool directory filename, it must be a | |
916 | data file created for or by an execution, and must begin with | |
917 | `D.'. | |
918 | ||
919 | TO | |
920 | The name to give the file on the slave. If this field names a | |
921 | directory the file is placed within that directory with the | |
922 | basename of FROM. A name ending in `/' is taken to be a | |
923 | directory even if one does not already exist with that name. If | |
924 | TO begins with `X.', an execution file will be created on the | |
925 | slave. Otherwise, if TO begins with `D.' it names a data file to | |
926 | be used by some execution file. Otherwise, TO should not be in | |
927 | the spool directory. | |
928 | ||
929 | USER | |
930 | The name of the user who requested the transfer. | |
931 | ||
932 | OPTIONS | |
933 | A list of options to control the transfer. The following options | |
934 | are defined (all options are single characters): | |
935 | ||
936 | `C' | |
937 | The file has been copied to the spool directory (the master | |
938 | should use TEMP rather than FROM). | |
939 | ||
940 | `c' | |
941 | The file has not been copied to the spool directory (this is | |
942 | the default). | |
943 | ||
944 | `d' | |
945 | The slave should create directories as necessary (this is | |
946 | the default). | |
947 | ||
948 | `f' | |
949 | The slave should not create directories if necessary, but | |
950 | should fail the transfer instead. | |
951 | ||
952 | `m' | |
953 | The master should send mail to USER when the transfer is | |
954 | complete. | |
955 | ||
956 | `n' | |
957 | The slave should send mail to NOTIFY when the transfer is | |
958 | complete. | |
959 | ||
960 | TEMP | |
961 | If the `C' option appears in OPTIONS, this names the file to be | |
962 | sent. Otherwise if FROM is in the spool directory, TEMP is the | |
963 | same as FROM. Otherwise TEMP is a dummy string, normally `D.0'. | |
964 | After the transfer has been succesfully completed, the master | |
965 | will delete the file TEMP. | |
966 | ||
967 | MODE | |
968 | This is an octal number giving the mode of the file on the | |
969 | master. If the file is not in the spool directory, the slave | |
970 | will always create it with mode 0666, except that if (MODE & | |
971 | 0111) is not zero (the file is executable), the slave will create | |
972 | the file with mode 0777. If the file is in the spool directory, | |
973 | some UUCP packages will use the algorithm above and some will | |
974 | always create the file with mode 0600 (Taylor UUCP does the | |
975 | latter). | |
976 | ||
977 | NOTIFY | |
978 | This field is only used if the `n' option appears in OPTIONS. | |
979 | Otherwise, it may not appear, or it may be the string `dummy', or | |
980 | it may simply be a pair of double quotes. If the `n' option is | |
981 | specified, then when the transfer is successfully completed the | |
982 | slave will send mail to NOTIFY, which must be a legal mailing | |
983 | address on the slave. | |
984 | ||
985 | SIZE | |
986 | This field is only present when doing size negotiation, either | |
987 | with Taylor UUCP or SVR4 UUCP. It is the size of the file in | |
988 | bytes. SVR4 UUCP sends the size in base 16 as 0x... while Taylor | |
989 | UUCP sends the size as a decimal integer (a later version of | |
990 | Taylor UUCP will probably change to the SVR4 behaviour). | |
991 | ||
992 | The slave then responds with an S command response. Taylor UUCP | |
993 | generates these responses in `freceive_file' and `ftransfer_fail'. | |
994 | ||
995 | `SY START' | |
996 | The slave is willing to accept the file, and file transfer | |
997 | begins. The START field will only be present when using SVR4 | |
998 | file restart. It specifies the byte offset into the file at | |
999 | which to start sending. If this is a new file, START will be 0x0. | |
1000 | ||
1001 | `SN2' | |
1002 | The slave denies permission to transfer the file. This can mean | |
1003 | that the destination directory may not be accessed, or that no | |
1004 | requests are permitted. It implies that the file transfer will | |
1005 | never succeed. | |
1006 | ||
1007 | `SN4' | |
1008 | The slave is unable to create the necessary temporary file. This | |
1009 | implies that the file transfer might succeed later. | |
1010 | ||
1011 | `SN6' | |
1012 | This is only used by Taylor UUCP size negotiation. It means that | |
1013 | the slave considers the file too large to transfer at the moment, | |
1014 | but it may be possible to transfer it at some other time. | |
1015 | ||
1016 | `SN7' | |
1017 | This is only used by Taylor UUCP size negotiation. It means that | |
1018 | the slave considers the file too large to ever transfer. | |
1019 | ||
1020 | If the slave responds with `SY', a file transfer begins. When the | |
1021 | file transfer is complete, the slave sends a `C' command response. | |
1022 | Taylor UUCP generates this confirmation in `fprecfile_confirm' and | |
1023 | checks it in `fpsendfile_confirm'. | |
1024 | ||
1025 | `CY' | |
1026 | The file transfer was successful. | |
1027 | ||
1028 | `CN5' | |
1029 | The temporary file could not be moved into the final location. | |
1030 | This implies that the file transfer will never succeed. | |
1031 | ||
1032 | After the `C' command response has been received (in the `SY' case) | |
1033 | or immediately (in an `SN' case) the master will send another command. | |
1034 | ||
1035 | \1f | |
1036 | File: uucp.info, Node: R Request, Next: X Request, Prev: S Request, Up: File Requests | |
1037 | ||
1038 | R Request | |
1039 | ......... | |
1040 | ||
1041 | master: `R FROM TO USER -OPTIONS SIZE' | |
1042 | ||
1043 | The `R' and the `-' are literal characters. This is a request by | |
1044 | the master to receive a file from the slave. I do not know how SVR4 | |
1045 | UUCP implements file transfer restart in this case. Taylor UUCP | |
1046 | implements the `R' request in `freceive_file'. | |
1047 | ||
1048 | FROM | |
1049 | This is the name of the file on the slave which the master wishes | |
1050 | to receive. It must not be in the spool directory, and it may | |
1051 | not contain any wildcards. | |
1052 | ||
1053 | TO | |
1054 | This is the name of the file to create on the master. I do not | |
1055 | believe that it can be a directory. It may only be in the spool | |
1056 | directory if this file is being requested to support an execution | |
1057 | either on the master or on some system other than the slave. | |
1058 | ||
1059 | USER | |
1060 | The name of the user who requested the transfer. | |
1061 | ||
1062 | OPTIONS | |
1063 | A list of options to control the transfer. The following options | |
1064 | are defined (all options are single characters): | |
1065 | ||
1066 | `d' | |
1067 | The master should create directories as necessary (this is | |
1068 | the default). | |
1069 | ||
1070 | `f' | |
1071 | The master should not create directories if necessary, but | |
1072 | should fail the transfer instead. | |
1073 | ||
1074 | `m' | |
1075 | The master should send mail to USER when the transfer is | |
1076 | complete. | |
1077 | ||
1078 | SIZE | |
1079 | This only appears if Taylor UUCP size negotiation is being used. | |
1080 | It specifies the largest file which the master is prepared to | |
1081 | accept (when using SVR4 UUCP, this was specified in the `-U' | |
1082 | option during the initial handshake). | |
1083 | ||
1084 | The slave then responds with an `R' command response. Taylor UUCP | |
1085 | generates these responses in `fsend_file' and `ftransfer_fail'. | |
1086 | ||
1087 | `RY MODE' | |
1088 | The slave is willing to send the file, and file transfer begins. | |
1089 | MODE is the octal mode of the file on the slave. The master uses | |
1090 | this to set the mode of the file on the master's system just as | |
1091 | the slave does the MODE argument in the send command (*note S | |
1092 | Request::.). | |
1093 | ||
1094 | `RN2' | |
1095 | The slave is not willing to send the file, either because it is | |
1096 | not permitted or because the file does not exist. This implies | |
1097 | that the file request will never succeed. | |
1098 | ||
1099 | `RN6' | |
1100 | This is only used by Taylor UUCP size negotiation. It means that | |
1101 | the file is too large to send, either because of the size limit | |
1102 | specifies by the master or because the slave considers it too | |
1103 | large. The file transfer might succeed later, or it might not | |
1104 | (this will be cleared up in a later release of Taylor UUCP). | |
1105 | ||
1106 | If the slave responds with `RY', a file transfer begins. When the | |
1107 | file transfer is complete, the master sends a `C' command. The slave | |
1108 | pretty much ignores this, although it may log it. Taylor UUCP sends | |
1109 | this confirmation in `fprecfile_confirm' and checks it in | |
1110 | `fpsendfile_confirm'. | |
1111 | ||
1112 | `CY' | |
1113 | The file transfer was successful. | |
1114 | ||
1115 | `CN5' | |
1116 | The temporary file could not be moved into the final location. | |
1117 | ||
1118 | After the `C' command response has been sent (in the `RY' case) or | |
1119 | immediately (in an `RN' case) the master will send another command. | |
1120 | ||
1121 | \1f | |
1122 | File: uucp.info, Node: X Request, Next: H Request, Prev: R Request, Up: File Requests | |
1123 | ||
1124 | X Request | |
1125 | ......... | |
1126 | ||
1127 | master: `X FROM TO USER -OPTIONS' | |
1128 | ||
1129 | The `X' and the `-' are literal characters. This is a request by | |
1130 | the master to, in essence, execute `uucp' on the slave. The slave | |
1131 | should execute `uucp FROM TO'. Taylor UUCP generates the `X' request | |
1132 | in `fxcmd' and handles it in `fdo_xcmd'. | |
1133 | ||
1134 | FROM | |
1135 | This is the name of the file or files on the slave which the | |
1136 | master wishes to transfer. Any wildcards are expanded on the | |
1137 | slave. If the master is requesting that the files be transferred | |
1138 | to itself, the request would normally contain wildcard | |
1139 | characters, since otherwise an `R' command would suffice. The | |
1140 | master can also use this command to request that the slave | |
1141 | transfer files to a third system. | |
1142 | ||
1143 | TO | |
1144 | This is the name of the file or directory to which the files | |
1145 | should be transferred. This will normally use a UUCP name. For | |
1146 | example, if the master wishes to receive the files itself, it | |
1147 | would use `MASTER!PATH'. | |
1148 | ||
1149 | USER | |
1150 | The name of the user who requested the transfer. | |
1151 | ||
1152 | OPTIONS | |
1153 | A list of options to control the transfer. It is not clear | |
1154 | which, if any, options are supported by most UUCP packages. | |
1155 | Taylor UUCP ignores the options field. | |
1156 | ||
1157 | The slave then responds with an X command response. Taylor UUCP | |
1158 | sends this response in either `fxcmd_confirm' or `ftransfer_fail'. | |
1159 | ||
1160 | `XY' | |
1161 | The request was accepted, and the appropriate file transfer | |
1162 | commands have been queued up for later processing. | |
1163 | ||
1164 | `XN' | |
1165 | The request was denied. No particular reason is given. | |
1166 | ||
1167 | In either case, the master will then send another command. | |
1168 | ||
1169 | \1f | |
1170 | File: uucp.info, Node: H Request, Prev: X Request, Up: File Requests | |
1171 | ||
1172 | H Request | |
1173 | ......... | |
1174 | ||
1175 | master: `H' | |
1176 | ||
1177 | This is used by the master to hang up the connection. The slave | |
1178 | will respond with an `H' command response. Taylor UUCP processes this | |
1179 | request in `fhangup_request', `fhangup_reply', and `fgetcmd'. | |
1180 | ||
1181 | `HY' | |
1182 | The slave agrees to hang up the connection. In this case the | |
1183 | master sends another `HY' command. In some UUCP packages, | |
1184 | including Taylor UUCP, the slave will then send a third `HY' | |
1185 | command. At this point the protocol is shut down, and the final | |
1186 | handshake is begun. | |
1187 | ||
1188 | `HN' | |
1189 | The slave does not agree to hang up. In this case the master and | |
1190 | the slave exchange roles. The next command will be sent by the | |
1191 | former slave, which is the new master. The roles may be reversed | |
1192 | several times during a single connection. | |
1193 | ||
1194 | \1f |