eftd [-a [ACCESS_FILE]] [-IlsV?] [-d LEVEL] [-D MASK] [-b LOGFILE] [-l LEVEL] [-L MASK] [-U FALLBACK_USER_ID] [-x ADDR]
Unless the -s option is given, the server loops forever waiting for incoming connections and forks a child process for each connection received.
For levels 0 - 3, see the -l option.
Higher values include more events in the log, such as low level protocol and call traces and temporarily inserted debugging output statements.
Use of -d as well as level > 3 is primarily intended for debugging purpose. This also implies that the output caused by log levels > 3 is not documented and likely to change between releases.
1 Important events related to session start and end (login and logout)
2 Important events during each session. Also adds some events related session start/stop of minor priority.
3 Other minor priority events.
>3 Low level events. As these are primarily useful for debugging purpose, it's probably better (but not strictly necessary) to log them by means of the -d option. See the latter for more info.
This option can be given two times, allowing the server to listen on two different x25 addresses simultaneously.
This is mainly useful for running eftd under the control of a debugger (such as gdb). If you want to debug eftd like this, also make sure that the '-m' option is not set. (As the -m option forks an additional supervisor process, -s alone will not result in a debuggable single process eftd). Further, as the single process will not run under root permissions any longer after an EUROFile connection has been accepted, eftd can not clear isdn connections on its own, you may need to do so yourself.
When multi mode is activated, the server forks an extra privileged supervisor process for each accepted connections which takes care of clearing the isdn connection after the session is finished. Thus, if N EURFILE sessions are active, there will be 2N+1 eftd processes.
You might use '-U ftp' if you have configured anonymous access and want that unknown user ids should be handled as an anonymous eft access. Unknown user ids frequently occur as many clients insert some dummy user name in the t_associate request if no user name was configured.
The server supports most of the EUROFILE primitives, including navigation and extended directory format. However, T-RENAME, T-DELETE, and LIST are not supported yet.
If eftd is compiled with the CONFIG_EFTD_WUAUTH option, user access is granted using an authentication procedure derived from wu-ftpd, the Washington University ftp server. Refer to the eft_wuauth man page for further details.
Transfers can be logged to /var/log/eft_xferlog. The format of this file is compatible with the wu-ftpd xferlog format. Refer to the eft_xferlog man page for details. Also see event logging below.
eftd can also be invoked (and then stopped) by means of the /etc/init.d/isdneurofile shell script:
/etc/init.d/isdneurofile start|stop
This script reads configuration parameters (usually from /etc/isdn/eft.conf). You might want to edit this file before starting it.
Besides starting eftd, the script also takes care of setting up the necessary isdn network interfaces. The script can be used by sysvinit to automatically start eft service as part of the system boot precedure. (But make sure it is called after isdn and x25 modules are loaded).
The EUROFILE protocol identifies files to be transferred by means of a so called `transfer name'. According to ETS 300-383/ETS 300-075, a transfer name may constist up to 8 keywords separated by the '/' character. Each keyword may constist of up to 12 printable (between 0x21 and 0x7e) ascii characters except '(', ')', '*', bytes.
The transfer names generated by eftd (and which will be displayed in response to a T-Directory request) will always conform to this.
eftd will also accept transfer names within incoming request (T-Load and T-Save request) that do not conform to the standards. If a transfer name in an incoming request is valid, it is processed by a mapping procedure which resolves to a file name. Transfer names not conforming to the standard are not subject to mapping. They are treated literally as POSIX filenames.
eftd maps transfer names to file names by means of two different methods. If the current working directory is writable by the user, a database is used that maps between transfer names and file names.
The database is currently implemented by means of symlinks which are created in the working directory. Symlinks matching .++eft_fn.TRANSFER_NAME contain the file name corresponding to TRANSFER_NAME. Symlinks matching .++eft_tn.FILE_NAME contain the transfer name name corresponding to FILE_NAME. You can clean tha database by just removing all those symlinks (rm .++eft_[ft]n.*).
If the directory is not writable by the user, an algorithm based ob the file/transfer name and the file's inode number is used to map between transfer names and file names.
eftd provides for two event logging channels. The first is always stderr, the other is the so called LogBook file (an ETS 300 383 term) (which might be altered by means of the -b option)
The amount of events logged can be controlled by a log level, which may be supplied by means of the -d (for stderr channel) or the -l (for LogBook file channel). An even finer grained (but even less portable) control is possible by means of bitmask arguments supplied with the -D or -L option.
For debugging purpose, it is somtimes helpful to write the standard error messages syncronized with the logged events into the same stream. Thus, for generating debugging logs, it is preferable to use the stderr channel. For debugging certain very low (i.e. Linux kernel) level protocol problems, it is even desirable to write the isdn events (as read from /dev/isdnctrl) to the same stream. eftd provides for a -I option to achieve this goal as close as possible (however, synchronity cannot be granted here).
Wenn large log levels are used, huge amounts of stderr output will be generated. Thus you might consider to redirect stderr to a disk file in such a case.
Writing to a log file might block the eftd process, which might result in timing problems if the process is blocked for a very long (several seconds) time. Thus, it is not advisable to log events to files (i.e. located on unreliable NFS servers) which are likly to cause such blocking.
The majority of DOS/Windows based clients implicitly assume that file transfer names fulfil DOS file name conventions and don't distinguish between upper and lower case names. This is in violation to the ETSI norms and might cause inter-working problems. The server provides for a compatibility mode to inter-operate with such clients. In order to activate that compatibility mode, prepend a '+' character to the login name when connecting to the server. See the doc/INTERWOKING file for details.
If you intend to offer files for public download via eft, it is recommended to use file names that match DOS conventions only.
Renaming and deleting (T-RENAME, T-DELETE) of files is not supported yet. The S-LIST primitive (recursivly listing all directories) is not supported.
Compression is not supported. This is not a serious limitation nowadays because on-disk compression formats like [g]zip are widley available, compress better, and also save disk storage. When eftp has established the connection, it issues the "eftp>" prompt and waits for commands that will be read from standard input. Interactive input can be edited by means of the GNU readline library.