Initial check in
This commit is contained in:
he
parent
7721350b09
commit
7f36d4e251
|
|
@ -0,0 +1,30 @@
|
|||
$Id: FAQ,v 1.1 1999/06/30 16:50:57 he Exp $
|
||||
|
||||
QUESTION: How can I control the amount of debugging output?
|
||||
=========
|
||||
|
||||
ANSWER:
|
||||
|
||||
eftd.c and eftp.c contain set a global variable tdu_stderr_mask.
|
||||
Locate this and change the comment characters (/* .. */). For only
|
||||
logging Error events, the final active statement should be
|
||||
|
||||
tdu_stderr_mask = TDU_LOG_ERR | TDU_LOG_IER;
|
||||
|
||||
To remove isdnlog output to stderr, you can also comment out the
|
||||
'tdu_open_isdtlog()' statement.
|
||||
|
||||
The eftd server now also allows to
|
||||
control the amount of debugging output via command line arguments,
|
||||
refer to the eftd(8) man page for further info.
|
||||
|
||||
|
||||
QUESTION: I don't want anonymous users to dial in without a MSN
|
||||
=========
|
||||
If a client without a MSN dials in, the ISDN number 0 is assumed.
|
||||
With the line "guestservers 1* 2* 3* 4* 5* 6* 7* 8* 9*" in
|
||||
/etc/isdn/eftaccess connections with ISDN numbers beginning with
|
||||
"0" are refused. Don't forget the option "-a" for eftd to make him
|
||||
the file /etc/isdn/eftaccess used.
|
||||
(What's about international connections then? Do they begin with "0"?
|
||||
I dont'n know, never had one...)
|
||||
|
|
@ -0,0 +1,166 @@
|
|||
$Id: INTERWORKING,v 1.1 1999/06/30 16:50:58 he Exp $
|
||||
|
||||
The following classes of inter-working problems have been identified
|
||||
====================================================================
|
||||
|
||||
Some clients rely on a particular order of file header parameters
|
||||
appearing in file headers or description files resulting from an
|
||||
extended format directory request. In particular, they fail when
|
||||
optional parameters appear before the mandatory ones.
|
||||
The current eftp4linux implementation works around this (without violating
|
||||
protocol specifications) by providing
|
||||
the mandatory parameters at the front of the file header or directory
|
||||
records and in the same order as appearing in ETS 300 383 (which
|
||||
does, however, not require for a particular order).
|
||||
|
||||
FileHeaderOrder (!) client depends on file attribute parameters
|
||||
appearing in a particular order inside file headers.
|
||||
|
||||
XDirOrder (!) client depends on file attribute parameters
|
||||
appearing in a particular order inside
|
||||
description file records resulting from an
|
||||
extended format directory request.
|
||||
|
||||
|
||||
Clients can ask the server for a list of files or subdirectories
|
||||
present the current working directory (by the T-DIR or S-LIST
|
||||
primitives). The server responds by sending back a file containing
|
||||
so-called transfer names (those are used to identify the files,
|
||||
but are not necessarily equal to the file
|
||||
names) or a list of subdirectory (`sub-filestore') names. Now,
|
||||
if the client wants to load a certain file or change to a certain
|
||||
directory, they need to send a request containing the desired transfer
|
||||
name or sub-filestore name. However, several clients don't use the
|
||||
transfer name as received from the server:
|
||||
|
||||
TransNameCases (+) upper/lower case letters are not preserved in
|
||||
transfer names
|
||||
DirNameCases (+) upper/lower case are not preserved in
|
||||
sub-filestore names
|
||||
DirNameSlash (+) client replaces slashes by backslashes in
|
||||
directory names
|
||||
|
||||
The eftp4linux server can work around those, but such workarounds
|
||||
impose additional restrictions. For example, if a there were two
|
||||
files README and ReadMe, with the work around active you cannot access
|
||||
both files any longer even when your clients is compliant with the
|
||||
protocol specification. Thus, the corresponding workarounds are not
|
||||
turned on by default, you need to explicitly request for them
|
||||
(currently, by prepending an '+' character in front of your user id).
|
||||
|
||||
TransNameTruncated the clients truncates parts of the transfer name
|
||||
(usually at the part until the last '/' character)
|
||||
DirNameTruncated (!) the clients truncates parts of the directory name
|
||||
(usually at the part until the last '/' character)
|
||||
|
||||
Truncating the transfer name at '/' has caused interworking problems
|
||||
with eftp4liux version 0.0.2 because that eftp4linux implementation
|
||||
inserted backslashes in filenames which are longer that 12 characters
|
||||
As a result, clients suffering from this bug could not access files
|
||||
with long file names.
|
||||
|
||||
ETS 300 383 refers to ETS 300 075 4.4.4,
|
||||
which requires transfer names to be composed by '/' separated
|
||||
words (each word not longer than 12 characters). By inserting '/'
|
||||
characters, the resulting transfer name becomes compliant with
|
||||
ETS 300 075 4.4.4, but the real originating file name is still
|
||||
guessible by a human reader (at least much better than something
|
||||
like "~FILE~.124"). Unfortunately, many clients have more problems
|
||||
with compliant transfer names than with non-compliant names.
|
||||
eftp4linux version 0.0.3 uses a database for mapping
|
||||
between transfer names an file names, this will hopefully solve
|
||||
that particual interwoking problem.
|
||||
|
||||
Truncating a directory name to its basename does not hurt so much
|
||||
because the basename is sufficient for identifying a directory inside the
|
||||
current working directory. (This will, however, currently not work if the
|
||||
directory name is a symlink).
|
||||
|
||||
Keep in mind that, even when your client's protocol implementation is
|
||||
able to access long file names, it might fail to load them because if
|
||||
your operating system does not support long file names.
|
||||
|
||||
x suffers from the problem
|
||||
+ suffers from the problem, but frequently works when compatibility mode
|
||||
("+userid") is activated.
|
||||
! suffers from the problem, but frequently that does not matter
|
||||
because current eftp4linux frequently can work around this without
|
||||
implying other restrictions.
|
||||
- suffers from the problem, but that does not matter any more
|
||||
because the current eftp4linux generally works around this.
|
||||
|
||||
|
||||
|
||||
FileHeaderOrder
|
||||
| XDirOrder
|
||||
| | TransNameCases
|
||||
| | | DirNameCases
|
||||
| | | | DirNameSlash
|
||||
| | | | | TransNameTruncated
|
||||
| | | | | | DirNameTruncated
|
||||
|
||||
eftp4linux client :-)
|
||||
|
||||
TELES.Fix 2.5
|
||||
TELES.Fix 4.0 - x
|
||||
TELES.Fix 6.0
|
||||
|
||||
AVM/FRITZ - + +
|
||||
|
||||
RVS-COM x !
|
||||
BIANCA ISDN
|
||||
|
||||
(As BIANCA supports unix, the developers might have been aware of the
|
||||
case sensitiveness problems. But unfortunately, I don't have any
|
||||
logs from BIANCA sessions where a long nameed file was tried to be
|
||||
downloaded.
|
||||
|
||||
|
||||
If blank, then nothing is known because, i.e.,
|
||||
- I received no connections attempting to use the corresponding feature
|
||||
- I received such attempts only after the corresponding workarounds
|
||||
were already implemented
|
||||
- the client does not support this feature at all
|
||||
- it works as it should work
|
||||
|
||||
Other observed connection attempts which were rejected due to wrong
|
||||
user IDs (not "ftp" or "+ftp")
|
||||
|
||||
TELES.FIX 3.07
|
||||
TELES.Fix 5.0
|
||||
TELES.Fix 6.01NT
|
||||
|
||||
|
||||
|
||||
There also seem to be inter-working problems related the ISO 8208
|
||||
(X.25 DTE-DTE) protocol which is used in the lower layers by Eurofile.
|
||||
(This is usually implemented by the CAPI driver)
|
||||
|
||||
Some broken clients (i.e. those based on the xxxx isdn toolbox) miss
|
||||
to pass mandatory X.25/ISO-8208 parameters with the X.25 call request
|
||||
(CAPI Connect-B3-Request). If the Capi driver is also buggy and does
|
||||
not detect and correct this, a misformatted, X.25 packet
|
||||
(violating X.25 specs) is send. Such packets currently confuse the
|
||||
Linux X.25 Layer. This has been observed with clients based on the
|
||||
CSD isdn toolbox. Similar symptoms observed with certain RVS clients
|
||||
might be caused by the same problem.
|
||||
|
||||
|
||||
There is a kernel patch, ix25-2.1.128.diff, which detects the misformatted
|
||||
packets and clears the call as required by the X.25 specification.
|
||||
However, this will not fix the interworking problem. For this,
|
||||
activate (uncomment) the #define at the last line of
|
||||
include/net/x25.h. This partially helps, but is not bullet proof.
|
||||
It has been reported to result in hangs when the buggy clients connect
|
||||
and try to download files. For interworking with such clients, try
|
||||
setting the facilities.winsize_in and facilities.winsize_out variable
|
||||
in eftd.c to 1.
|
||||
|
||||
|
||||
Miscc/open questions
|
||||
|
||||
Should the .. directory be present in the file generated in response
|
||||
to an [S]LIST request? AVM/Fritz clients generate this entry locally
|
||||
which causes .. to be displayed twice if the server also included a ..
|
||||
entry in the SLIST response file.
|
||||
|
||||
|
|
@ -0,0 +1,15 @@
|
|||
$Id: INTERWORKING.de,v 1.1 1999/06/30 16:50:58 he Exp $
|
||||
|
||||
Bisher ist Interworking der 0.0.2-Version mit den folgenden
|
||||
Protokollimplementierungen offenbar (teilweise) erfolgreich gewesen.
|
||||
|
||||
- mit der eigenen (Linux) EUROFile Implementierung als Gegenstelle
|
||||
- AVM/Fritz
|
||||
- TELES
|
||||
- BIANCA ISDN
|
||||
- RVS-COM Lite Version 1.22
|
||||
|
||||
(wobei trotzdem Probleme wie unten beschrieben auftreten können,
|
||||
genaueres steht im File INTERWORKING in der Distribution)
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,90 @@
|
|||
$Id: PROBLEME.eftd,v 1.1 1999/06/30 16:50:59 he Exp $
|
||||
|
||||
Die Implementierung ist noch nicht komplett, folgende Probleme sind
|
||||
bekannt:
|
||||
|
||||
- Navigation (so heißt bei EUROfile alles, was mit Directories zu tun hat)
|
||||
ist noch nicht vollständig protokollkonform unterstützt. Hier sind
|
||||
zuvor noch einige offene Fragen zu klären. (s.u.)
|
||||
Zur Zeit wird immer der durch realpath(3) kanonisierte Directory-Pfad als
|
||||
Filestore-Name benutzt. Dies kann dazu führen, daß Filestorenamen
|
||||
mehrfach auftreten, wenn sie unter verschiedenen Namen (symlinks)
|
||||
erreichbar sind (oder gewisse Links ganz ausgeblendet werden).
|
||||
Es wird auch noch keine global eindeutige Information über die
|
||||
Anordnung der Filestores untereinander ("Filestore Reference")
|
||||
erzeugt. Das könnte zu Problemen führen, wenn ein besonders
|
||||
intelligenter Client versucht, die Directory-Struktur des Servers
|
||||
local nachzubilden.
|
||||
|
||||
- Bei einigen Clients wurden Probleme mit der Groß/Klein-schreibung
|
||||
von Transfernamen beobachtet. Manche Clients benutzen sogar für
|
||||
die Übertragung in der einen Richtung grundsätzlich Transfernamen in
|
||||
Großbuchstaben, für die Gegenrichtung in Kleinbuchstaben. Da der Linux Server
|
||||
die Transfernamen als Dateinamem (und nach Unix-Manier case sensitive)
|
||||
interpretiert, können solche Clients ihre eigenen, gerade geschriebenen
|
||||
Dateien nicht wieder zurücklesen. Nach den EUROFile Normen (ETS 300 383 /
|
||||
ETS 300 075) sollten Transfernamen case-sensitive sein (zumindest steht
|
||||
da nichts Gegenteiliges). Daher betrachte ich dieses Problem eigentlich
|
||||
nicht als meines, bis mich jemand eines besseren belehrt. Seltsamerweise
|
||||
habe ich auch schon connections von Clients gleicher Herstller gehabt, die
|
||||
die Groß/Kleinschreibung konsistent benutzt haben. Daher vermute ich, daß das
|
||||
Problem im User Interface der Software begründet ist und sich daher die
|
||||
DOS, Win3.1, und Win95 Versionen oder gar dieselbe eft
|
||||
Client-Version unter verschieden Windows-Version möglicherweise
|
||||
unterschiedlich verhalten.
|
||||
|
||||
Wer einen Client mit solchen Problemen hat, kann einen
|
||||
Kompatibilitätsmodus aktivieren, indem er dem Login-Namen ein
|
||||
'+'-Zeichen voranstellt (z.B. userid "+ftp" statt "ftp"). Dann
|
||||
wird Groß/Kleinschreibung bei Dateinamen ignoriert,
|
||||
Directory-Prefixe werden stets in Kleinbuchstaben konvertiert.
|
||||
Damit sind natürlich gewisse Dateien mit dem Eurofile-Protokoll
|
||||
nicht mehr zugreifbar.
|
||||
|
||||
- Die meisten Clients scheinen offenbar, wenn man keinen login Namen
|
||||
angibt, irgendeinen Default Namen (z.B wurde "No Name" bei Teles
|
||||
beobachtet) zu verwenden. Das Einloggen geht dann schief, wenn
|
||||
kein login account mit Namen "No Name" existiert. Um dem
|
||||
vorzubeugen, solltet ihr grundsätzlich einen login-namen explizit
|
||||
angeben (und zwar "ftp" bzw. "+ftp" bei anonymem Zugang).
|
||||
|
||||
- Die Datumsübertragung im ETS 300 075 Protokoll ist nicht y2k safe!
|
||||
|
||||
- Die maximale Länge von übertragbaren Dateien ist durch gewisse
|
||||
Restriktionen im ETS 300 075 Protokoll begrenzt (auf ca 64 MByte bei
|
||||
üblicher 1k Blockgröße).
|
||||
|
||||
|
||||
|
||||
Offene Fragen:
|
||||
|
||||
UNIX geht davon aus, daß die Dateistruktur eine gemeinsame Wurzel "/"
|
||||
hat. Einzelne User haben darin Home-Directories.
|
||||
EUROFile geht davon aus, daß jeder User einen Default-Filestore
|
||||
(analog Home-Directory) hat, der gleichzeitig die logische Wurzel
|
||||
aller erreichbaren Sub-Filestore's (analog Sub-Directories) ist.
|
||||
Dieser Unterschied schlägt insbesondere bei Dateien zu, die nicht
|
||||
unterhalb des Home-Directories des Benutzers liegen.
|
||||
Die offene Frage ist, ob und wie diese unterschiedliche logische Sicht
|
||||
auf den Dateibaum im Server umgesetzt werden soll.
|
||||
|
||||
Da die meisten Unix-ähnlichen Betriebssysteme Symlinks haben, ist
|
||||
dasselbe Directory unter Umständen unter mehreren verschiedenen Namen
|
||||
erreichbar, so daß die durch Datei/Directory-Namen beschriebene Struktur
|
||||
nicht zwangsläufig eine reine Baumstruktur darstellt. EUROFILE geht
|
||||
dagegen von einer logisch reinen Baumstruktur aus.
|
||||
Die offene Frage ist, ob und wie der Server den Zugriff auf
|
||||
Directories über Symlinks zulassen soll. Der einfachste Weg, eine
|
||||
logische Baumstruktur für eft zur Verfügung zu stellen, besteht darin,
|
||||
Symlinks zu Directories einfach auszublenden. Dann kann man natürlich
|
||||
die ganzen Vorteile, die Symlinks in der Administration bieten, für
|
||||
Eurofile nicht mehr nutzen (und z.B. bestehende ftp-Archive mit
|
||||
Symlinks nur eingeschränkt über EUROFile zuganglich machen).
|
||||
Vielleicht kann man auch die Einschränkungen aus ETS 300 383
|
||||
einfach ignorieren, aber das bringt unter Umständen
|
||||
protokollkonforme Clients durcheinander. Andere Lösungen
|
||||
(Vorschläge willkommen) erfordern wohl mehr Implementierungsaufwand.
|
||||
|
||||
(Für die detailierte Beschreibung/Analyse der Interworking-Probleme siehe
|
||||
auch das File INTERWORKING in der Distribution).
|
||||
|
||||
|
|
@ -0,0 +1,54 @@
|
|||
$Id: PROBLEMS-2.1.114,v 1.1 1999/06/30 16:51:00 he Exp $
|
||||
|
||||
Known problems observed when using X.25 on top of isdn with kernel 2.1.126
|
||||
==========================================================================
|
||||
|
||||
The X.25 PLP implementation was originally designed to be used on top
|
||||
of a synchronous line (accessed via an X.25 network device driver)
|
||||
or on top of lan (IEEE 802 LLC type 2). Furthermore, the X.25
|
||||
implementation as well as the related isdn4linux extensions are labelled
|
||||
as "EXPERIMENTAL" code in the kernel source tree. Thus, the X.25 protocol
|
||||
sometimes doesn't behave as you would expect, in particular when used
|
||||
on top of isdn.
|
||||
|
||||
|
||||
Problems related to isdn drivers:
|
||||
=================================
|
||||
|
||||
The isdnloop HL driver apparently has problems to re-establish a
|
||||
connection that has been hung up from the outgoing device. You have to
|
||||
unload the isdnloop driver after the faked isdn-connection is closed
|
||||
and insmod it again. With the Hisax driver, this problem is not present.
|
||||
|
||||
When ifconfig'ing isdn network interfaces (with encap x25iface set) down,
|
||||
"disconnect indication while unconfigured" messages might appear in
|
||||
the syslog. This does not indicate any problem and can be ignored.
|
||||
|
||||
When establishing the first X.25 connection on a link, there is a
|
||||
delay of some seconds until the link becomes established. This is only
|
||||
a performance problem and harmless. Furthermore, this is fixed with
|
||||
recent isdn4linux versions from the isdn4linux CVS tree.
|
||||
|
||||
Problems related to the X.25 PLP implementation:
|
||||
================================================
|
||||
|
||||
isdn B channels are not closed automatically when the X.25 PLP
|
||||
connection is closed. If you are lucky, your peer does it. Thus,
|
||||
monitor your isdn connections while using X.25 on top of isdn4linux
|
||||
(i.e. by watching syslog messages or by an isdn monitor program).
|
||||
You need to close the B channel connection by hand (using the
|
||||
"isdnctrl hangup" command) or rely on the isdn network interface's
|
||||
hangup timeout. The scripts provided with this this test distribution
|
||||
try to provide workourounds for this.
|
||||
|
||||
Kernels prior to 2.1.125 have a bug in include/linux/x25.h which
|
||||
has been reported to cause compilation problems on glibc2 systems.
|
||||
|
||||
2.1.127 introduced changes that broke current i4l CVS isdn subsystem.
|
||||
Until this is fixed, only use cvs isdn with 2.1.126 or older.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
$Id: README,v 1.1 1999/06/30 16:51:00 he Exp $
|
||||
|
||||
For previewing man pages (i.e. efthosts.5), use
|
||||
|
||||
nroff -man efthosts.5 | less
|
||||
|
||||
|
|
@ -0,0 +1,223 @@
|
|||
|
||||
|
||||
Expert start
|
||||
============
|
||||
|
||||
This is an older setup procedure kept for compatibility and expert
|
||||
users who want to do more with x25 on top of isdn4linux.
|
||||
(this is no longer supported but as you are an expert user, you might
|
||||
want to edit the scripts such that it works with this release again).
|
||||
|
||||
Even if you don't use isdn, this might be useful for testing PF_X25
|
||||
network applications. The test distribution supports
|
||||
setting up X.25 connections on top of the isdnloop driver. This allows
|
||||
you to set up X25 connections between a client and a server application
|
||||
running on the same machine. There is no physical x25 network
|
||||
interface needed. This is similar to setting up tcp/ip connections
|
||||
to the "localhost" IP address. (Using the isdn subsystem for this
|
||||
might be overkill, but there is currently no other x25 loop device
|
||||
driver at all).
|
||||
|
||||
A script "ix25test" is provided inside the scripts
|
||||
directory. That script does all the necessary setups needed for
|
||||
testing x.25 on top of isdn4linux. You need to edit the script to
|
||||
account for your local configuration (i.e. your MSN, ISDN-numbers
|
||||
of your peer, location of utility binaries and kernel sources/modules,
|
||||
configuration of your isdn HL driver, ...).
|
||||
You should unload all isdn drivers modules and the x25 module before
|
||||
calling this script.
|
||||
|
||||
When done, you can just call "ix25test start". However, read the
|
||||
comments in the script file as well as the remaining part of this
|
||||
README file and the PROBLEMS.* files before using it.
|
||||
|
||||
|
||||
Now the really cool stuff in detail:
|
||||
|
||||
1. Boot your (patched) kernel (see remarks below)
|
||||
|
||||
2. log in as root
|
||||
|
||||
3. Make sure that all isdn and x25 related modules are unloaded. I also
|
||||
prefer to switch to runlevel 1 (using the command "init 1") when doing
|
||||
my tests, this will usually unload all isdn drivers as well.
|
||||
|
||||
Call the configuration script:
|
||||
|
||||
ix25test start telnetd 01
|
||||
|
||||
(In case of problems, issue the command "ix25test stop", fix
|
||||
the script, and repeat)
|
||||
|
||||
4. switch to another virtual terminal, log in (not as root), and
|
||||
start the x25 based telnet client. Assuming your x25 based telnet
|
||||
client resides in x25bin/telnet enter the command
|
||||
|
||||
x25bin/telnet 00 01
|
||||
|
||||
This will open an x25-based telnet session on top of isdn4linux
|
||||
to your own machine. The isdnloop HL driver is used for this, thus
|
||||
no real isdn line is occupied (and no phone bill will result from
|
||||
this). If it works you should be able to log in, issue some commands
|
||||
and log out again.
|
||||
|
||||
5. After exiting from the telnet session, switch back to the other
|
||||
virtual console (where you started the ix25test script) and type
|
||||
^C. This should kill the telnetd and shut down the test
|
||||
configuration again.
|
||||
|
||||
|
||||
If this worked well you can try x.25 connections on top of real isdn
|
||||
connections to your own computer. Similar procedure as above, but
|
||||
slightly different command arguments:
|
||||
|
||||
|
||||
3. ix25test start telnetd 03
|
||||
|
||||
4. x25bin/telnet 00 03
|
||||
|
||||
This will establish a real isdn connection on top of hisax to yourself
|
||||
(your PTT will probably charge you). Please monitor (i.e by watching
|
||||
syslog messages) the isdn connections during and after your tests.
|
||||
(Verify that connections are properly released after your tests and
|
||||
no power dialing or other expensive actions happen during your tests.)
|
||||
|
||||
|
||||
If this worked you might try a connection to a remote computer. Find a
|
||||
partner operates an EUROFILE server and agrees that you connect to it
|
||||
with this experimental software.
|
||||
|
||||
1. boot the test configuration as above. Alternatively, as you don't need
|
||||
an x.25 based server on your own machine, "ix25test start" is
|
||||
sufficient.
|
||||
|
||||
2. Assuming your user name on the eft server is "myname" and your
|
||||
password is "mypass", switch to the non-root virtual console and type
|
||||
|
||||
eftp 05 myname/mypass
|
||||
|
||||
from the shell's prompt. This will try to connect to the remote
|
||||
eft server.
|
||||
|
||||
3. type
|
||||
|
||||
dir *
|
||||
|
||||
from the "eftp>" prompt to list the directory of the eft server.
|
||||
|
||||
4. type
|
||||
|
||||
get <filename> [<local filename>]
|
||||
|
||||
from the "eftp>" prompt, where <filename> denotes a file name
|
||||
present on the remote server (such as listed by the previously
|
||||
issued "dir"-command). This will download that file.
|
||||
|
||||
5. type
|
||||
|
||||
put <filename> [<remote filename>]
|
||||
|
||||
to upload a file to the remote server. (This is known not to inter-work
|
||||
with certain remote eftp servers when used with an unpatched 2.1.92
|
||||
kernel).
|
||||
|
||||
6. type
|
||||
|
||||
quit
|
||||
|
||||
to exit from the eft session.
|
||||
|
||||
7. switch to the root shell's virtual console and type
|
||||
|
||||
ix25test stop
|
||||
|
||||
(or just ^C, if a server has been started) to shut down the test
|
||||
configuration. The eftp program doesn't hangup the isdn line after
|
||||
the eft connection is closed. (This is currently impossible
|
||||
because the x25 socket interface does not provide for this
|
||||
functionality). Therefor, it is recommended that you manually
|
||||
hang up the isdn line (using "isdnctrl hangup" or shutting down
|
||||
the test configuration). Your eft peer might close the isdn
|
||||
connection after the eft session is finished, but you should not
|
||||
rely on that.
|
||||
|
||||
|
||||
|
||||
You can also try to connect with your eftp client locally to the tdu.echod
|
||||
server by
|
||||
|
||||
ix25test start tdu.echod 01
|
||||
|
||||
and then
|
||||
|
||||
eftp 01 myname/mypass.
|
||||
|
||||
However, as tdu.echod is not an eft server implementation, you will
|
||||
only be able connect and disconnect. Any attempt to transfer files will
|
||||
only trigger error events of the EUROFILE protocol implementation.
|
||||
|
||||
|
||||
PLEASE, keep in mind that the eftp client (OVER-)writes local files.
|
||||
In case of bugs, the file overwritten might be different from the file
|
||||
which you specified in the target parameter of the "get" command.
|
||||
|
||||
|
||||
If it doesn't work, what to do?
|
||||
===============================
|
||||
|
||||
Well, this is alpha-test software and you should be able to assist
|
||||
me in troubleshooting. To make this task more convenient, the ix25test
|
||||
script provides some debugging support.
|
||||
|
||||
If you use the script and it fails before any B-channel connection got
|
||||
set up you probably did not edit the script successfully. Check it.
|
||||
|
||||
If your syslog / isdnctrl messages indicate that the isdn b-channel
|
||||
was successfully set up but no further data seems to be transferred,
|
||||
there might be an inter-working problem of the X.25 PLP implementations.
|
||||
Uncomment the line in the ix25test script where the x25trace program
|
||||
is started and try again. This will leave a protocol trace in /tmp
|
||||
which might be helpful in tracking down the problem. If you cannot
|
||||
resolve such a problem yourself, please include that trace output in
|
||||
your bug report.
|
||||
|
||||
If the x.25 connections set up successfully, but eft doesn't work, the
|
||||
eft error messages reported by eftp program might reveal the problem.
|
||||
The eft protocol implementation is incomplete. Thus, failures are not
|
||||
not unlikely to occur.
|
||||
|
||||
If the standard error messages don't contain
|
||||
enough information, you can make the eft programmes a lot more noisy
|
||||
if you locate the line in eftp.c where the variable tdu_stderr_mask
|
||||
is set. Change this to
|
||||
|
||||
tdu_stderr_mask = -1
|
||||
|
||||
and recompile. A lot of debugging output (protocol and call trace)
|
||||
will appear on your terminal while the eftp program is running now.
|
||||
|
||||
|
||||
Problems with the kernel part might also be present. Please refer to
|
||||
the appropriate PROBLEMS-* file available from the same site as this
|
||||
test distribution. But I consider the kernel stuff (x25 on top of
|
||||
isdn4linux extensions), which I've used since end of May 1997 now with
|
||||
only marginal modifications, to be much more stable than the user
|
||||
level eft implementation. However, if you faced a serious kernel bug
|
||||
(usually indicated by an oops messages in the syslog output) please
|
||||
report it to me. The oops message will only be meaningful to me if
|
||||
the addresses are reported in symbolic form. Thus, if you faced a
|
||||
kernel oops, compile the ksymoops program present in your kernel
|
||||
sources "script" directory, i.e (assuming kernel source is in
|
||||
/home/kernel/linux-ix25):
|
||||
|
||||
cd /home/kernel/linux-ix25/scripts
|
||||
g++ ksymoops.cc -o ksymoops
|
||||
|
||||
The ix25test script leaves a System.map file in the /tmp directory
|
||||
which contains all symbolic address mappings of the resident
|
||||
kernel as well as all isdn and x25 related modules. You can use this
|
||||
file with your ksymoops program. For your convenience, ix25test also
|
||||
leaves a script "oops_decode" left in /tmp. Type "/tmp/oops_decode"
|
||||
after the oops happened, this will fetch the oops message from your
|
||||
/var/log/messages syslog protocol file and decode it to stdout.
|
||||
|
||||
|
|
@ -0,0 +1,354 @@
|
|||
$Id: design.txt,v 1.1 1999/06/30 16:51:01 he Exp $
|
||||
|
||||
This document is to briefly intruduce the EUROFILE protocol stack
|
||||
and to document the design of the eftp4linux EUROFILE implementation.
|
||||
It is derived from an original 'white paper' that I've written to
|
||||
introduce the isdn4linux EUROFILE deveoping project to other developeres.
|
||||
|
||||
Enjoy,
|
||||
|
||||
Henner
|
||||
|
||||
|
||||
Contents: 0.0 How to Read This
|
||||
|
||||
1.1 EUROFILE Protocol Stack, General Aspects
|
||||
1.2 The ISO 8208 Protocol
|
||||
1.3 The Data Link Protocols
|
||||
|
||||
2.1 ISO 8208 / X.25 inside Linux
|
||||
2.2 Socket User Interface to Protocol Layer
|
||||
2.3 Data Links in Linux: X.25 LAP_B vs. isdn4linux x75i
|
||||
|
||||
3.1 Encapsulation
|
||||
3.2 L2 Protocol
|
||||
3.3 Providing Data-link Control Primitives to the x25 Packet Layer
|
||||
|
||||
4. EUROFILE protocol higher layers themselves and their
|
||||
implementation (currently empty :-)
|
||||
|
||||
0.0 How to Read This
|
||||
====================
|
||||
|
||||
This document serves two purposes:
|
||||
|
||||
- It give a brief introduction on how i4l was interfaced with the
|
||||
X.25 network layer (sections 3.* of this article). If you are familiar
|
||||
with EFT related protocols and (isdn4)linux internals you can goto 3.0
|
||||
right away and submit your comments.
|
||||
|
||||
- It also givea an introduction on EFT, and ideas how it was
|
||||
implemented in linux. Since it took quite some time for me
|
||||
to gather all the information related to EFT, I decided to write an
|
||||
introduction as the initial task of the linux EFT project. That
|
||||
introduction was also a good base for documentation.
|
||||
|
||||
|
||||
Sections 1.* will provide the necessary background information.
|
||||
|
||||
Sections 2.* will provide background information concerning linux specific
|
||||
EFT related protocol issues. If you focus on the user level part of the
|
||||
EFT implementation 2.2 will be the most (or even only) important part for you.
|
||||
|
||||
In sections 3.* I'd like to discuss implementation issues concerning the
|
||||
kernel related part. Please comment on that (no matter, whether
|
||||
you are participating in the EFT project or not). You won't need to reed
|
||||
this if you are not interested in the kernel related stuff (but I've
|
||||
tried to describe my ideas from the i4l end users point of view).
|
||||
|
||||
Section 4 is to suggest a development strategy.
|
||||
|
||||
|
||||
I've asked all EFT volunteers to subscribe to the i4l developer list. Since
|
||||
I don't know whether all of them have already subscribed I also include
|
||||
their addresses explicitly
|
||||
|
||||
|
||||
1.1 EUROFILE Protocol Stack, General Aspects
|
||||
============================================
|
||||
|
||||
From my point of view EFT is functionally similar to ftp (the purpose is to
|
||||
transfer files), although the protocols used by them are totally different.
|
||||
ftp runs on top of the TCP/IP protocol. EFT does not run on top of the
|
||||
well supported TCP/IP protocol suite. It uses the less known (in the Unix
|
||||
world) ISO-8208 network protocol instead.
|
||||
|
||||
TCP/IP and ISO-8208 provide similar services to the applications, namely a
|
||||
connection oriented, reliable, multiplexed, and flow-controlled exchange of
|
||||
data. There are also some differences, i.e. ISO-8208 preserves messages
|
||||
boundaries while tcp/ip just provides reliable byte streams. And
|
||||
ISO-8208 also has some strange stuff such as qualified data (which is
|
||||
used by EUROFILE).
|
||||
|
||||
|
||||
1.2 The ISO 8208 Protocol
|
||||
=========================
|
||||
|
||||
ISO 8208 is similar to the packet layer protocol standardised by ITU-T
|
||||
recommendation X.25. X.25 is widely applied in many public data networks
|
||||
such as the German Datex-P network.
|
||||
|
||||
I didn't get the ISO-8208 specification yet, all of my
|
||||
knowledge is from secondary sources. Thus, please correct me if I'm wrong!
|
||||
But as I understand others, the differences between ITU X.25 and ISO 8208
|
||||
are marginal (as far as the core functionality is concerned):
|
||||
|
||||
- ITU wanted to standardise the access to public data network switches.
|
||||
Therefore, ITU specified the protocol as viewded from the network
|
||||
switch (the Data Circuit Equipment "DCE")
|
||||
- ISO describes the protocol in terms of the user equipment (the Data Terminal
|
||||
equipment "DTE") that wants to communicate via the network.
|
||||
|
||||
Both standards essentially define the same protocol (but probably, the ISO
|
||||
version has much more optional features which will never get implemented -:).
|
||||
|
||||
ITU X.25 specifies a whole protocol stack used to connect to X.25 switches
|
||||
including the X.25 Packet Layer Protocol ("PLP", the network layer/layer 3
|
||||
in terms of the OSI model), data link protocol ("LAP_B", OSI layer 2) and a
|
||||
physical layer (OSI layer 1). ISO-8208 is just concerned with the network
|
||||
layer.
|
||||
|
||||
I guess one could also say that ITU describes the process of communicating
|
||||
with an X.25 network switch (which will route the packets) while ISO
|
||||
describes how to communicate with your peer entity. Thus, ITU X.25 is also
|
||||
refered as X.25 DTE-DCE. ISO, in contrast, also covers direct communication
|
||||
of two X.25 peer entities (without involving an X.25 switch). This mode
|
||||
of operation is frequently refered as X.25 DTE-DTE.
|
||||
|
||||
And this DTE-DTE mode is also used by EFT when operating over ISDN!
|
||||
|
||||
You can argue that the use of a network protocol like X.25 (which supports
|
||||
routing and other stuff) is unnecessary when operating over a circuit
|
||||
switched ISDN (and thus a waste of resources). You might be right,
|
||||
but I didn't design the EFT protocol. So, don't blame me for that.
|
||||
|
||||
|
||||
1.3 The Data Link Protocols
|
||||
===========================
|
||||
|
||||
ITU X.25 PLP and ISO 8208 run on top of a data link protocol. ITU X.25
|
||||
defines the LAP_B procedure itself. ISO-8208 doesn't define a data link
|
||||
protocol itself. The layer-3 Protocol is just defined in terms of certain
|
||||
data link service primitives which must be provided by the data link entity.
|
||||
|
||||
Protocols, which provide the data link service to ISO8208 are defined in
|
||||
other ISO standards. I.e. a LAP_B protocol, which provides
|
||||
such data link services, is defined in ISO 7776. ISO 7776 is (almost) identical
|
||||
to the X.75 data link protocol. This layer-2 protocol is well known by
|
||||
isdn4linux users who frequently choose it for tty-style connections in order
|
||||
to benefit from its error recovery features.
|
||||
|
||||
X.75 by itself defines ITU's protocol stack to interconnect public
|
||||
X.25 networks. Beside the data link protocol known by linux users, it
|
||||
also defines (like X.25) a packet layer / layer 3 protocol which
|
||||
is also very similar to X.25 PLP. We won't need any more information on
|
||||
these (and other) X.75 procedures.
|
||||
|
||||
The ISO 7776 or X.75 LAP_B protocol is again similar to the LAP_B procedure
|
||||
defined in ITU X.25.
|
||||
|
||||
In contrast to the packet layer / layer 3 protocols
|
||||
the data link protocols are not purely symmetric:
|
||||
The lap_b protocols work by exchanging "commands" and "responses".
|
||||
Commands and responses are submitted on different data link addresses (the
|
||||
protocols contain an address field to support this).
|
||||
Usually, one peer submits commands using the data link address 1 and submits
|
||||
responses using the data link address 3. The other peer sends commands on
|
||||
address 3 and responses on address 1. Thus, before communication can start,
|
||||
a decision has to be made on who is going to submit commands on data link 1
|
||||
and on who must submit them on address 3.
|
||||
|
||||
With X.25, this decision is quite simple. The rule is that the DTE side
|
||||
sends the commands on address 1 while the DCE sends the commands on address 3.
|
||||
|
||||
With X.75 or ISO-8208 there is no difference between the peers. Both peer
|
||||
entities are functionally equivalent. Fortunately, for isdn, there is always
|
||||
one side which must set up the physical isdn B channel connection by
|
||||
calling the other side before communication can start. The rule is
|
||||
that the calling party uses the addresses like the DTE while the called
|
||||
party uses the addresses like the DCE.
|
||||
|
||||
Thus, when EFT is operated over ISDN, the latter rules will be applied.
|
||||
|
||||
When you configure the X.75 l2-protocol, isdn4linux will automatically
|
||||
choose the proper data link addresses according to the rule above.
|
||||
|
||||
|
||||
|
||||
2.1 ISO 8208 / X.25 inside Linux
|
||||
================================
|
||||
|
||||
Obviously, since EFT runs on top of ISO 8208, we definitely need an ISO
|
||||
8208 protocol implementation before we can think about EFT. Fortunately,
|
||||
Jonathan Naylor has add X.25 support to Linux (first kernel version
|
||||
with X.25 was 2.1.16). This implementation was based on ITU-T X.25
|
||||
specificatiion. But this also works well in the ISO 8208 DTE-DTE context.
|
||||
|
||||
|
||||
2.2 Socket User Interface to Protocol Layer
|
||||
===========================================
|
||||
|
||||
In Unix-like operating systems, ftp clients and servers are usually
|
||||
implemented as user space programs which access the TCP/IP network protocol
|
||||
service of the kernel by means of the socket interface. EFT does not run on
|
||||
top of tcp/ip, but on top of the ISO 8208 protocol. But an operating system
|
||||
can also provide access to the ISO 8208 / X.25 protocol by means of a socket
|
||||
interface. Thus, EFT servers and clients might be similarly implemented as
|
||||
user space programs like ftp or ftpd. The Linux X.25 implementation provides
|
||||
such a socket interface.
|
||||
|
||||
To obtain information on socket programming you can start with "man socket".
|
||||
There are also a lot of books which describe socket programming.
|
||||
|
||||
|
||||
User space ftp eft
|
||||
|
||||
Socket Interface ------------ ------------
|
||||
|
||||
tcp x25
|
||||
Kernel Space
|
||||
ip lap_b
|
||||
|
||||
|
||||
A lot of programmers are familiar with tcp/ip programming using the socket
|
||||
interface. Since tcp/ip and x.25 provide similar services to the user,
|
||||
programming an application that communicates via the X.25 protocol is
|
||||
not essentially different from programming a tcp/ip application. However,
|
||||
there are still some differences:
|
||||
|
||||
First, the address space and protocol family will be different
|
||||
(PF/AF_INET vs. PF/AF_X25). For EUROFILE which applies X.25 in DTE-DTE
|
||||
mode we can use an empty X.25 address anyway.
|
||||
|
||||
Second, in contrast to tcp/ip, X.25 preserves packet
|
||||
boundaries. Thus, a SOCK_SEQPACKET type socket is used for X.25 while
|
||||
tcp/ip uses SOCK_STREAM type sockets. If you write N bytes to a SOCK_SEQPACKET
|
||||
socket using the Unix write() system call, then a read()
|
||||
from the corresponding peer socket will return the same N bytes of data
|
||||
as written. With stream sockets, this is generally not the case (the boundaries
|
||||
of the written and read chunks won't necessarily match).
|
||||
|
||||
EFT also needs so called X25 qualified data to be transmitted.
|
||||
The Linux X.25 protocol stack supports a special socket option that
|
||||
makes the X.25 Q-Bit (which is used by the X.25 PLP to mark qualified
|
||||
data packets) transparent to the uses.
|
||||
|
||||
|
||||
2.3 Data Links in Linux: X.25 LAP_B vs. isdn4linux x75i
|
||||
==========================================================
|
||||
|
||||
X25 needs a data link protocol implementation. The Linux X25 PLP is designed
|
||||
to interface directly to a Linux network interface. It requires the network
|
||||
interface to implement the X.25 data link protocol (this design decision has
|
||||
been made in order to make use of intelligent X25 cards which implement the
|
||||
LAP_B protocol in firmware). Jonathan Naylor has also written a lapb_module
|
||||
which can be used by all x25 network interface driver developers who don't
|
||||
want to implement the lap_b protocol on their own (see
|
||||
Documentation/networking/lapb-module.txt).
|
||||
|
||||
i4l also supports a lap_b protocol (l2_prot x75i). The protocol is also
|
||||
implemented below the network interface. Thus, the situation was almost as
|
||||
required by the X25 PLP implementation.
|
||||
|
||||
However, there was one difference:
|
||||
|
||||
In the beginning of the isdn4linux EUROFILE project, i4l's x.75 only
|
||||
allowed the upper protocol layers to send and receive data.
|
||||
A user might send data to the i4l x.75 data link entity at any time.
|
||||
When the data link is in the "connected" state, than i4l's x.75 protocol
|
||||
implementation will just send the data to the peer. If the data link is not
|
||||
in the "connected" state then i4l will automatically established the data link
|
||||
first. After it has been established, the data will be send. No special user
|
||||
intervention was (and still is) needed for establishing the data link,
|
||||
i4l takes care on this.
|
||||
|
||||
The X25 PLP protocol, in contrast, wants to control the establishment
|
||||
and release of the data link by itself. Therefore, an X.25 lap_b
|
||||
implementation must provide all the lap_b service primitives
|
||||
(DL_DATA request/indication, DL_ESTABLISH request/indication/confirm,
|
||||
DL_RELEASE request/indication/confirm) to the upper protocol layers (and in
|
||||
turn doesn't need to bother with automatic establishment procedures). Each
|
||||
message exchanged between the X.25 LAP_B network interface and the X25 PLP
|
||||
gets prepended a special byte. This byte is used to distinguish between the
|
||||
different DL service primitives. It is not part of the protocol data units to
|
||||
be sent to or received from the peer. (see
|
||||
Documentation/networking/x25-iface.txt for details)
|
||||
|
||||
Remark: The lapb module only provides the protocol implementation. The
|
||||
interpretation of the leading control byte as defined in x25-iface.txt
|
||||
must be performed by the x25-network-interface-device driver which uses
|
||||
the lapb module.
|
||||
|
||||
|
||||
3. Providing the X.25 lap_b Interface in i4l
|
||||
=============================================
|
||||
|
||||
3.1 Encapsulation
|
||||
=================
|
||||
|
||||
Some method of providing the LAP_B data link service primitives to
|
||||
the Linux X.25 layer needed to be implemented.
|
||||
|
||||
This was done by means of a new encapsulation type for isdn4linux
|
||||
network interfaces. This encapsulation is turned on in the same manner
|
||||
as all other encapsulation, namely by the isdnctrl command, e.g.
|
||||
|
||||
"isdnctrl encap isdn0 x25iface"
|
||||
|
||||
configures an isdn4linux network interface for use by the X25 PLP.
|
||||
|
||||
This is only to indicate that the messages sent through the network interface
|
||||
are formatted according to the Linux' x25-lapb interface specification.
|
||||
(it might also be used by the device driver to take special actions which are
|
||||
specific for communicating with the x25 PLP layer). But the encapsulation
|
||||
doesn't specify how lower parts of i4l system will provide the data link
|
||||
service. (the encap doesn't specify the data link protocol which provides the
|
||||
data link service, but the protocol used between the network device and the
|
||||
network protocol layers).
|
||||
|
||||
|
||||
3.2 L2 Protocol
|
||||
===============
|
||||
|
||||
The data link protocol used to communicate between two peers is specified
|
||||
as usual by the l2_prot parameter. For EFT,
|
||||
|
||||
"isdnctrl l2_prot isdn0 x75i"
|
||||
|
||||
is used and no new protocol implementation was necessary.
|
||||
|
||||
However, it might be a good opportunity to reserve two new
|
||||
l2_prot parameters, namly x25_dte and x25_dce. These specify almost the same
|
||||
as x75i, the only difference is that the data link addresses used for commands
|
||||
and responses will be fixed (in X.75 they depend on who initiates the
|
||||
corresponding call).
|
||||
|
||||
The x25_dte or dce l2-protocols are not needed for EFT, but
|
||||
they might enable other x25 users to access public x25 data networks by
|
||||
means of i4l b_channels (dialup as well as leased lines). Maybe some
|
||||
x25 folks will be quite happy about this.
|
||||
|
||||
|
||||
3.3 Providing Data Link Control Primitives to the x25 Packet Layer
|
||||
==================================================================
|
||||
|
||||
One design question was how to provide the LAP_B protocol service by i4l.
|
||||
(interpreting and setting the first byte and mapping them on the DL primitives
|
||||
according to Documentation/networking/x25-iface.txt).
|
||||
|
||||
The final implementation used the existing x.75 L2 protocol
|
||||
present in the HL level drivers but implemented the processing of the
|
||||
first-byte (as specified in Documentation/networking/x25-iface.txt)
|
||||
entirely in the isdn4linux link level module. This
|
||||
was possible without any extension to the isdn4linux LL-HL driver interface.
|
||||
Thus, no hardware level driver needed to be adopted and every hardware
|
||||
level driver that supports l2prot x75i can be used for EUROFILE.
|
||||
(This already turned out to be a FAQ: does Linux EUROFILE work with my
|
||||
xy-isdn-card? Answer: Yes, if the card supports l2prot x75i. In
|
||||
patricular all cards supported by HiSax work)
|
||||
|
||||
|
||||
4. EUROFILE protocol higher layers themselves and their implementation
|
||||
======================================================================
|
||||
|
||||
TO BE ADDED
|
||||
|
|
@ -0,0 +1,182 @@
|
|||
.\" $Id: eft_wuauth.5,v 1.1 1999/06/30 16:51:02 he Exp $
|
||||
.\" Copyright (c) 1985, 1988 The Regents of the University of California.
|
||||
.\" All rights reserved.
|
||||
.\"
|
||||
.\" Redistribution and use in source and binary forms are permitted provided
|
||||
.\" that: (1) source distributions retain this entire copyright notice and
|
||||
.\" comment, and (2) distributions including binaries display the following
|
||||
.\" acknowledgement: ``This product includes software developed by the
|
||||
.\" University of California, Berkeley and its contributors'' in the
|
||||
.\" documentation or other materials provided with the distribution and in
|
||||
.\" all advertising materials mentioning features or use of this software.
|
||||
.\" Neither the name of the University nor the names of its contributors may
|
||||
.\" be used to endorse or promote products derived from this software without
|
||||
.\" specific prior written permission.
|
||||
.\" THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED
|
||||
.\" WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
|
||||
.\" MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
|
||||
.\"
|
||||
.\" ORIGINAL: ftpd.8 6.8 (Berkeley) 6/24/90
|
||||
.\"
|
||||
.\" @(#)$Original-Id: ftpd.8,v 1.5 1997/01/14 22:45:27 sob Exp sob $
|
||||
.\"
|
||||
.TH EFT_WUAUTH 5 "Jan 10, 1997"
|
||||
.UC 5
|
||||
.SH NAME
|
||||
eft_wuauth \- authentication for eftp4linux Eurofile server based on wuftpd.
|
||||
.SH DESCRIPTION
|
||||
If the eftp4linux Eurofile server
|
||||
.I eftd
|
||||
is compiled with the CONFIG_EFTD_WUAUTH configuration option,
|
||||
it uses user authentication code derived from
|
||||
.I wuftpd,
|
||||
the Washington University ftp daemon.
|
||||
.PP
|
||||
In that case
|
||||
.I eftd
|
||||
authenticates users according to four rules.
|
||||
.IP 1)
|
||||
The user name must be in the password data base,
|
||||
.IR /etc/passwd ,
|
||||
or whatever is appropriate for the operating system,
|
||||
and the password must not be null. In this case a password
|
||||
must be provided by the client before any file operations
|
||||
may be performed.
|
||||
.IP 2)
|
||||
The user name must not appear in the file
|
||||
.IR /etc/isdn/eftusers .
|
||||
.IP 3)
|
||||
The user must have a standard shell returned by
|
||||
.IR getusershell (3).
|
||||
If login failed for certain users, maybe that's because their login
|
||||
shell is not listed in /etc/shells.
|
||||
.IP 4)
|
||||
If the user name is ``anonymous'' or ``ftp'', an
|
||||
anonymous ftp account must be present in the password
|
||||
file (user ``ftp''). In this case the user is allowed
|
||||
to log in by specifying any password (by convention this
|
||||
is given as the client host's name).
|
||||
.PP
|
||||
In the last case,
|
||||
.I eftd
|
||||
takes special measures to restrict the client's access privileges.
|
||||
The server performs a
|
||||
.IR chroot (2)
|
||||
command to the home directory of the ``ftp'' user.
|
||||
In order that system security is not breached, it is recommended
|
||||
that the ``ftp'' subtree be constructed with care; the following
|
||||
rules are recommended.
|
||||
.IP ~ftp)
|
||||
Make the home directory owned by super-user and unwritable by anyone.
|
||||
.IP ~ftp/bin)
|
||||
Make this directory owned by the super-user and unwritable by
|
||||
anyone. This contains auxilary programs that might be forked by
|
||||
.IR eftd(8)
|
||||
or
|
||||
.IR ftpd(8).
|
||||
These programs should have mode 111.
|
||||
.IR eftd(8)
|
||||
currently does not need any auxilary programs. Thus, you only need to
|
||||
put files here if you also want to provide anonymous ftp service.
|
||||
.IP ~ftp/etc)
|
||||
Make this directory owned by the super-user and unwritable by
|
||||
anyone. The files
|
||||
.IR passwd (5)
|
||||
and
|
||||
.IR group (5)
|
||||
must be present for eftd
|
||||
to be able to produce owner names rather than numbers in file headers
|
||||
and extended format directory (T-DIR primitive) listings. Depending
|
||||
on the operating system, there may be other required files. Check your
|
||||
manual page for the
|
||||
.IR getpwent (3)
|
||||
library routine.
|
||||
The password field in
|
||||
.I passwd
|
||||
is not used, and should not contain real encrypted passwords.
|
||||
These files should be mode 444 and owned by the super-user.
|
||||
Don't use the system's /etc/passwd file as the password file or
|
||||
the system's /etc/group file as the group file in the ~ftp/etc directory.
|
||||
.IP ~ftp/pub)
|
||||
Create a subdirectory in ~ftp/pub
|
||||
with the appropriate mode (777 or 733) if you want to allow normal
|
||||
users to upload files.
|
||||
|
||||
.PP
|
||||
The Eurofile file server also allows for finer grained access control
|
||||
by means of the files /etc/isdn/eftaccess and /etc/isdn/efthosts.
|
||||
|
||||
.SH "COPYING"
|
||||
The main part of eftp4linux is licensed under the LGPL. However,
|
||||
eft servers using the wuauth authentication libray also contain code
|
||||
copyrighted by the University of California, Berkeley,
|
||||
by the Washington University in Saint Louis, and their contributors.
|
||||
That code is subject to a BSD style licences with advertisment clause:
|
||||
|
||||
Copyright (c) 1990 The Regents of the University of California.
|
||||
All rights reserved.
|
||||
|
||||
This code is derived from software contributed to Berkeley by
|
||||
Chris Torek.
|
||||
Redistribution and use in source and binary forms are permitted
|
||||
provided that: (1) source distributions retain this entire
|
||||
copyright notice and comment, and (2) distributions including binaries
|
||||
display the following acknowledgement: ``This product includes software
|
||||
developed by the University of California, Berkeley and its contributors''
|
||||
in the documentation or other materials provided with the distribution
|
||||
and in all advertising materials mentioning features or use of this
|
||||
software. Neither the name of the University nor the names of its
|
||||
contributors may be used to endorse or promote products derived
|
||||
from this software without specific prior written permission.
|
||||
THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
|
||||
IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
|
||||
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
|
||||
Copyright (c) 1993, 1994 Washington University in Saint Louis
|
||||
All rights reserved.
|
||||
|
||||
Redistribution and use in source and binary forms, with or without
|
||||
modification, are permitted provided that the following conditions
|
||||
are met: 1. Redistributions of source code must retain the above
|
||||
copyright notice, this list of conditions and the following
|
||||
disclaimer.
|
||||
2. Redistributions in binary form must reproduce the above copyright
|
||||
notice, this list of conditions and the following disclaimer in the
|
||||
documentation and/or other materials provided with the distribution.
|
||||
3. All advertising materials mentioning features or use of this
|
||||
software must display the following acknowledgement: This product
|
||||
includes software developed by the Washington University in Saint
|
||||
Louis and its contributors.
|
||||
4. Neither the name of the University nor the names of its
|
||||
contributors may be used to endorse or promote products derived from
|
||||
this software without specific prior written permission.
|
||||
|
||||
THIS SOFTWARE IS PROVIDED BY WASHINGTON UNIVERSITY AND CONTRIBUTORS
|
||||
``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
|
||||
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
|
||||
FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL WASHINGTON
|
||||
UNIVERSITY OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
|
||||
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
|
||||
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
|
||||
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
|
||||
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
||||
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
|
||||
ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
|
||||
POSSIBILITY OF SUCH DAMAGE.
|
||||
|
||||
|
||||
|
||||
.SH "SEE ALSO"
|
||||
.BR eftd(1) ,
|
||||
.BR shells(5) ,
|
||||
.BR getusershell(3) ,
|
||||
.BR eftaccess(5) ,
|
||||
.BR efthosts(5) ,
|
||||
.BR eft_xferlog(5) ,
|
||||
.BR umask(2)
|
||||
.SH BUGS
|
||||
The anonymous account is inherently dangerous and should be
|
||||
avoided when possible.
|
||||
|
||||
The eftaccess amd efthosts files are currently not yet working as documented.
|
||||
|
|
@ -0,0 +1,168 @@
|
|||
.\" $Id: eft_xferlog.5,v 1.1 1999/06/30 16:51:03 he Exp $
|
||||
.TH EFT_XFERLOG 5
|
||||
.SH NAME
|
||||
eft_xferlog \- EFT server logfile
|
||||
.SH DESCRIPTION
|
||||
.LP
|
||||
The
|
||||
.B eft_xferlog
|
||||
file contains logging information from the eftp4linux eurofile server daemon,
|
||||
.BR eftd (8).
|
||||
This file usually is found in /var/adm, but can be located anywhere by using a
|
||||
option to
|
||||
.BR eftd (8).
|
||||
.P
|
||||
eftd uses the same format as wu-ftpd for its log files. Thus, you
|
||||
might be able to use or adapt tools that have been written to analyse
|
||||
wu-ftpd xferlog files. However, for some fields of the log file
|
||||
different semantics apply. This is because they are now
|
||||
related to the isdn domain rather than the internet.
|
||||
.P
|
||||
Each server entry is composed of a single line of the following form,
|
||||
with all fields being separated by spaces.
|
||||
.IP
|
||||
.I
|
||||
current-time\ \ transfer-time\ \ remote-host\ \ file-size\ \ filename\ \ transfer-type\ \ special-action-flag\ \ direction\ \ access-mode\ \ username\ \ service-name\ \ authentication-method\ \ authenticated-user-id
|
||||
.LP
|
||||
.TP 20
|
||||
.I current-time
|
||||
is the current local time in the form "DDD MMM dd hh:mm:ss YYYY". Where DDD
|
||||
is the day of the week, MMM is the month, dd is the day of the month,
|
||||
hh is the hour, mm is the minutes, ss is the seconds, and YYYY is the year.
|
||||
.TP
|
||||
.I transfer-time
|
||||
is the total time in seconds for the transfer.
|
||||
.TP
|
||||
.I remote-host
|
||||
is the remote host's isdn number.
|
||||
.TP
|
||||
.I file-size
|
||||
is the size of the transferred file in bytes.
|
||||
.TP
|
||||
.I filename
|
||||
is the name of the transferred file.
|
||||
.TP
|
||||
.I transfer-type
|
||||
is a single character indicating the type of transfer. Can be one of:
|
||||
.RS
|
||||
.RS
|
||||
.PD 0
|
||||
.TP 10
|
||||
.B a
|
||||
for an ascii transfer
|
||||
.TP
|
||||
.B b
|
||||
for a binary transfer
|
||||
.PD
|
||||
.RE
|
||||
.RE
|
||||
As eftp4linux only supports binary transfers, this will
|
||||
allways be 'b'.
|
||||
.TP
|
||||
.I special-action-flag
|
||||
is one or more single character flags indicating any special action taken.
|
||||
Can be one or more of:
|
||||
.RS
|
||||
.RS
|
||||
.PD 0
|
||||
.TP 10
|
||||
.B C
|
||||
file was compressed
|
||||
.TP
|
||||
.B U
|
||||
file was uncompressed
|
||||
.TP
|
||||
.B T
|
||||
file was tar'ed
|
||||
.TP
|
||||
.B _
|
||||
no action was taken
|
||||
.PD
|
||||
.RE
|
||||
.RE
|
||||
As on-the-fly-compression is not supported by eftp4linux,
|
||||
this will always be '_'.
|
||||
.TP
|
||||
.I direction
|
||||
is the direction of the transfer. Can be one of:
|
||||
.RS
|
||||
.RS
|
||||
.PD 0
|
||||
.TP 10
|
||||
.B o
|
||||
outgoing
|
||||
.TP
|
||||
.B i
|
||||
incoming
|
||||
.PD
|
||||
.RE
|
||||
.RE
|
||||
.TP
|
||||
.I access-mode
|
||||
is the method by which the user is logged in. Can be one of:
|
||||
.RS
|
||||
.RS
|
||||
.PD 0
|
||||
.TP 10
|
||||
.B a
|
||||
(anonymous) is for an anonymous guest user.
|
||||
.TP
|
||||
.B g
|
||||
(guest) is for an passworded guest user (see the
|
||||
.BR guestgroup
|
||||
command in
|
||||
.BR eftaccess(5)
|
||||
).
|
||||
.TP
|
||||
.B r
|
||||
(real) is for a local authenticated user.
|
||||
.PD
|
||||
.RE
|
||||
.RE
|
||||
.TP
|
||||
.I username
|
||||
is the local username, or if guest, the ID string given.
|
||||
.TP
|
||||
.I service-name
|
||||
is the name of the service being invoked, which is EFT.
|
||||
.TP
|
||||
.I authentication-method
|
||||
is the method of authentication used. Can be one of:
|
||||
.RS
|
||||
.RS
|
||||
.PD 0
|
||||
.TP 10
|
||||
.B 0
|
||||
none
|
||||
.TP
|
||||
.B 1
|
||||
RFC931 Authentication
|
||||
.PD
|
||||
.RE
|
||||
.RE
|
||||
As RFC931 authentication is not used by eftp4linux, this will always
|
||||
be 0.
|
||||
.TP
|
||||
.I authenticated-user-id
|
||||
is the user id returned by the authentication method.
|
||||
A * is used if an authenticated user id is not available. With
|
||||
eftp4linux, this will be the same as the user name.
|
||||
.SH CREDITS
|
||||
.LP
|
||||
This man page has been derived from the wuftpd
|
||||
.BR xferlog(5)
|
||||
man page. Please refer to the
|
||||
.BR eft_wuauth(5)
|
||||
man page for further details.
|
||||
.SH FILES
|
||||
.PD 0
|
||||
.TP 20
|
||||
.B /var/log/xferlog
|
||||
.SH "SEE ALSO"
|
||||
.BR ftpd(8),
|
||||
.BR ftpaccess(5),
|
||||
.BR xferlog(5),
|
||||
.BR eftd(8),
|
||||
.BR eftaccess(5),
|
||||
.BR eft_wuauth(5)
|
||||
|
||||
|
|
@ -0,0 +1,334 @@
|
|||
.\" $Id: eftaccess.5,v 1.1 1999/06/30 16:51:04 he Exp $
|
||||
.\" SCCSID: @(#)$Original-Id: ftpaccess.5,v 1.7 1997/01/10 06:27:02 sob Exp $
|
||||
.\"
|
||||
.\"
|
||||
.TH eftaccess 5
|
||||
.SH Name
|
||||
eftaccess \- eftd configuration file
|
||||
.SH Description
|
||||
The eftaccess file is used to configure the operation of
|
||||
.BR eftd(1) .
|
||||
.SH Access Capabilities
|
||||
.TP 0.5i
|
||||
.B autogroup <groupname> <class> [<class> ...]
|
||||
If an ANONYMOUS user is a member of any of <class>, the ftp
|
||||
server will perform a setegid() to <groupname>. This allows
|
||||
access to group-and-owner-read-only files and directories to
|
||||
a particular class of anonymous users. <groupname> is a valid
|
||||
group from /etc/group (or wherever mechanism your
|
||||
.IR getgrent(2)
|
||||
library routine uses).
|
||||
.TP 0.5i
|
||||
.B class <class> <typelist> <addrglob> [<addrglob> ...]
|
||||
Define <class> of users, with source addresses of the form
|
||||
<addrglob>. Multiple members of <class> may be defined. There
|
||||
may be multiple "class" commands listing additional members of
|
||||
the class. If multiple "class" commands can apply to the
|
||||
current session, the first one listed in the access file is
|
||||
used. Failing to define a valid class for a host will cause
|
||||
access to be denied. <typelist> is a comma-separated list of
|
||||
any of the keywords "anonymous", "guest" and "real". If the
|
||||
"real" keyword is included, the class can match users using FTP
|
||||
to access real accounts, and if the "anonymous" keyword is
|
||||
included the class can match users using anonymous FTP. The
|
||||
"guest" keyword matches guest access accounts (see "guestgroup"
|
||||
for more information)
|
||||
|
||||
<addrglob> may be a globbed isdn number.
|
||||
.TP 0.5i
|
||||
.B deny <addrglob> <message_file>
|
||||
Always deny access to host(s) matching <addrglob>. <message_file>
|
||||
is displayed.
|
||||
.TP 0.5i
|
||||
.B guestgroup <groupname> [<groupname> ...]
|
||||
If a REAL user is a member of any of <groupname>, the session
|
||||
is set up exactly as with anonymous FTP. In other words, a
|
||||
chroot() is done, and the user is no longer permitted to issue
|
||||
the USER and PASS commands. <groupname> is a valid group
|
||||
from /etc/group (or whatever mechanism your
|
||||
.IR getgrent(3)
|
||||
library routine uses).
|
||||
|
||||
The user's home directory must be properly set up, exactly as
|
||||
anonymous FTP would be. The home directory field of the
|
||||
passwd entry is divided into two directories. The first
|
||||
field is the root directory which will be the argument
|
||||
to the
|
||||
.IR chroot(2)
|
||||
call. The second half is the user's
|
||||
home directory relative to the root directory. The
|
||||
two halves are separated by a "/./".
|
||||
|
||||
Example:
|
||||
|
||||
in /etc/passwd, the real entry:
|
||||
|
||||
guest1:<passwd>:100:92:Guest Account:/ftp/./incoming:/etc/ftponly
|
||||
|
||||
When guest1 successfully logs in, the ftp server will
|
||||
chroot("/ftp") and then chdir("/incoming"). The
|
||||
guest user will only be able to access the directory structure
|
||||
under /ftp (which will look and act as / to guest1), just as an
|
||||
anonymous FTP user would.
|
||||
.TP 0.5i
|
||||
.B limit <class> <n> <times> <message_file>
|
||||
(currently not applicable to eftd)
|
||||
.P
|
||||
Limit <class> to <n> users at times <times>, displaying
|
||||
<message_file> if user is denied access. Limit check is
|
||||
performed at login time only. If multiple "limit" commands can
|
||||
apply to the current session, the first applicable one is
|
||||
used. Failing to define a valid limit, or a limit of -1, is
|
||||
equivalent to unlimited. <times> is in same format as the times
|
||||
in the UUCP L.sys file.
|
||||
.TP 0.5i
|
||||
.B noretrieve <filename> <filename> ....
|
||||
(currently not applicable to eftd)
|
||||
.P
|
||||
Always deny retrieve-ability of these files. If the files are an
|
||||
absolute path specification (i.e. begins with '/' character) then
|
||||
only those files are marked un-gettable, otherwise all files with
|
||||
matching the filename are refused transfer. Example:
|
||||
|
||||
noretrieve /etc/passwd core
|
||||
|
||||
specifies no one will be able to get the file /etc/passwd whereas
|
||||
they will be allowed to transfer a file `passwd' if it is not in
|
||||
/etc. On the other hand no one will be able to get files named
|
||||
`core' wherever it is.
|
||||
|
||||
No globbing is done.
|
||||
.TP 0.5i
|
||||
.B loginfails <number>
|
||||
(currently not applicable to eftd)
|
||||
.P
|
||||
After <number> login failures, log a "repeated login failures"
|
||||
message and terminate the FTP connection. Default value is 5.
|
||||
.TP 0.5i
|
||||
.SH Informational Capabilities
|
||||
.TP 0.5i
|
||||
.B banner <path>
|
||||
Works similarly to the message command, except that the banner
|
||||
is displayed before the user enters the username/password. The
|
||||
<path> is relative to the real system root, not the base of the
|
||||
anonymous FTP directory.
|
||||
.TP 0.5i
|
||||
.B email <name>
|
||||
Defines the email address of the ftp archive maintainer. This string
|
||||
will be printed every time the %E magic cookie is used.
|
||||
.TP 0.5i
|
||||
.B message <path> {<when> {<class> ...}}
|
||||
(currently not applicable to eftd)
|
||||
.P
|
||||
Define a file with <path> such that ftpd will display the
|
||||
contents of the file to the user login time or upon using the
|
||||
change working directory command. The <when> parameter may be
|
||||
"LOGIN" or "CWD=<dir>". If <when> is "CWD=<dir>", <dir>
|
||||
specifies the new default directory which will trigger the
|
||||
notification.
|
||||
|
||||
The optional <class> specification allows the message to be
|
||||
displayed only to members of a particular class. More than one
|
||||
class may be specified.
|
||||
|
||||
There can be "magic cookies" in the readme file which cause the
|
||||
ftp server to replace the cookie with a specified text string:
|
||||
|
||||
%T local time (form Thu Nov 15 17:12:42 1990)
|
||||
%F free space in partition of CWD (kbytes)
|
||||
[not supported on all systems]
|
||||
%C current working directory
|
||||
%E the maintainer's email address as defined in ftpaccess
|
||||
%R remote host name
|
||||
%L local host name
|
||||
%u username as determined via RFC931 authentication
|
||||
%U username given at login time
|
||||
%M maximum allowed number of users in this class
|
||||
%N current number of users in this class
|
||||
|
||||
The message will only be displayed once to avoid annoying the
|
||||
user. Remember that when MESSAGEs are triggered by an
|
||||
anonymous FTP user, the <path> must be relative to the base of
|
||||
the anonymous FTP directory tree.
|
||||
.TP 0.5i
|
||||
.B readme <path> {<when> {<class>}}
|
||||
Define a file with <path> such that ftpd will notify user at
|
||||
login time or upon using the change working directory command
|
||||
that the file exists and was modified on such-and-such date.
|
||||
The <when> parameter may be "LOGIN" or "CWD=<dir>". If <when>
|
||||
is "CWD=<dir>", <dir> specifies the new default directory which
|
||||
will trigger the notification. The message will only be
|
||||
displayed once, to avoid bothering users. Remember that when
|
||||
README messages are triggered by an anonymous FTP user, the
|
||||
<path> must be relative to the base of the anonymous FTP
|
||||
directory tree.
|
||||
|
||||
The optional <class> specification allows the message to be
|
||||
displayed only to members of a particular class. More than one
|
||||
class may be specified.
|
||||
.SH Logging Capabilities
|
||||
.TP 0.5i
|
||||
.B log commands <typelist>
|
||||
Enables logging of individual commands by users. <typelist> is
|
||||
a comma-separated list of any of the keywords "anonymous",
|
||||
"guest" and "real". If the "real" keyword is included, logging
|
||||
will be done for users using FTP to access real accounts, and
|
||||
if the "anonymous" keyword is included logging will done for
|
||||
users using anonymous FTP. The "guest" keyword matches guest
|
||||
access accounts (see "guestgroup" for more information).
|
||||
.TP 0.5i
|
||||
.B log transfers <typelist> <directions>
|
||||
Enables logging of file transfers for either real or anonymous
|
||||
FTP users. Logging of transfers TO the server (incoming) can
|
||||
be enabled separately from transfers FROM the server
|
||||
(outbound). <typelist> is a comma-separated list of any of the
|
||||
keywords "anonymous", "guest" and "real". If the "real"
|
||||
keyword is included, logging will be done for users using FTP
|
||||
to access real accounts, and if the "anonymous" keyword is
|
||||
included logging will done for users using anonymous FTP. The
|
||||
"guest" keyword matches guest access accounts (see "guestgroup"
|
||||
for more information). <directions> is a comma-separated list
|
||||
of any of the two keywords "inbound" and "outbound", and will
|
||||
respectively cause transfers to be logged for files sent to the
|
||||
server and sent from the server.
|
||||
.SH Miscellaneous Capabilities
|
||||
.TP 0.5i
|
||||
.B alias <string> <dir>
|
||||
Defines an alias, <string>, for a directory. Can be
|
||||
used to add the concept of logical directories.
|
||||
|
||||
For example:
|
||||
alias rfc: /pub/doc/rfc
|
||||
|
||||
would allow the user to access /pub/doc/rfc from any
|
||||
directory by the command "cd rfc:". Aliases only
|
||||
apply to the cd command.
|
||||
.TP 0.5i
|
||||
.B cdpath <dir>
|
||||
Defines an entry in the cdpath. This defines a search path that is used
|
||||
when changing directories.
|
||||
|
||||
For example:
|
||||
|
||||
cdpath /pub/packages
|
||||
cdpath /.aliases
|
||||
|
||||
would allow the user to cd into any directory directly under
|
||||
/pub/packages or /.aliases directories. The search path is defined by
|
||||
the order the lines appear in the ftpaccess file.
|
||||
|
||||
If the user were to give the command:
|
||||
|
||||
cd foo
|
||||
|
||||
The directory will be searched for in the following order:
|
||||
|
||||
./foo
|
||||
an alias called "foo"
|
||||
/pub/packages/foo
|
||||
/.aliases/foo
|
||||
|
||||
The cd path is only available with the cd command. If you have a large
|
||||
number of aliases you might want to set up an aliases directory with
|
||||
links to all of the areas you wish to make available to users.
|
||||
.TP 0.5i
|
||||
|
||||
.SH Permission Capabilities
|
||||
(currently not applicable to eftd)
|
||||
.P
|
||||
.TP 0.5i
|
||||
.B chmod <yes|no> <typelist>
|
||||
.TP 0.5i
|
||||
.B delete <yes|no> <typelist>
|
||||
.TP 0.5i
|
||||
.B overwrite <yes|no> <typelist>
|
||||
.TP 0.5i
|
||||
.B rename <yes|no> <typelist>
|
||||
.TP 0.5i
|
||||
.B umask <yes|no> <typelist>
|
||||
Allows or disallows the ability to perform
|
||||
the specified function. By default, all users
|
||||
are allowed.
|
||||
|
||||
<typelist> is a comma-separated list of any of the
|
||||
keywords "anonymous", "guest" and "real".
|
||||
.TP 0.5i
|
||||
.B passwd-check <none|trivial|rfc822> (<enforce|warn>)
|
||||
Define the level and enforcement of password checking
|
||||
done by the server for anonymous ftp.
|
||||
|
||||
none no password checking performed.
|
||||
trivial password must contain an '@'.
|
||||
rfc822 password must be an rfc822 compliant address.
|
||||
|
||||
warn warn the user, but allow them to log in.
|
||||
enforce warn the user, and then log them out.
|
||||
.TP 0.5i
|
||||
.B path-filter <typelist> <mesg> <allowed_charset> {<disallowed regexp> ...}
|
||||
(currently not applicable to eftd)
|
||||
.P
|
||||
For users in <typelist>, path-filter defines regular expressions
|
||||
that control what a filename can or can not be. There may be
|
||||
multiple disallowed regexps. If a filename is invalid due to
|
||||
failure to match the regexp criteria, <mesg> will be displayed to
|
||||
the user. For example:
|
||||
|
||||
path-filter anonymous /etc/pathmsg ^[-A-Za-z0-9\._]*$ ^\. ^-
|
||||
|
||||
specifies that all upload filenames for anonymous users must be
|
||||
made of only the characters A-Z, a-z, 0-9, and "._-" and may not
|
||||
begin with a "." or a "-". If the filename is invalid, /etc/pathmsg
|
||||
will be displayed to the user.
|
||||
.TP 0.5i
|
||||
.B upload <root-dir> <dirglob> <yes|no> <owner> <group> <mode> ["dirs"|"nodirs"]
|
||||
Define a directory with <dirglob> that permits or
|
||||
denies uploads.
|
||||
|
||||
If it does permit uploads, all files will be owned
|
||||
by <owner> and <group> and will have the permissions
|
||||
set according to <mode>.
|
||||
|
||||
Directories are matched on a best-match basis.
|
||||
|
||||
For example:
|
||||
upload /var/ftp * no
|
||||
upload /var/ftp /incoming yes ftp daemon 0666
|
||||
upload /var/ftp /incoming/gifs yes jlc guest 0600 nodirs
|
||||
|
||||
This would only allow uploads into /incoming and
|
||||
/incoming/gifs. Files that were uploaded to
|
||||
/incoming would be owned by ftp/daemon and would
|
||||
have permissions of 0666. File uploaded to
|
||||
/incoming/gifs would be owned by jlc/guest and
|
||||
have permissions of 0600. Note that the <root-dir> here must
|
||||
match the home directory specified in the password database for the
|
||||
"ftp" user.
|
||||
|
||||
The optional "dirs" and "nodirs" keywords can be
|
||||
specified to allow or disallow the creation of
|
||||
new subdirectories using the mkdir command.
|
||||
|
||||
The upload keyword only applies to users who
|
||||
have a home directory (the argument to the chroot() )
|
||||
of <root-dir>.
|
||||
.SH Files
|
||||
FTPLIB/ftpaccess
|
||||
.SH See Also
|
||||
.BR ftpd(8),
|
||||
.BR umask(2) ,
|
||||
.BR ftplog(5) ,
|
||||
.BR ftpconversions(5) ,
|
||||
.BR ftpshut(8)
|
||||
.SH BUGS
|
||||
The eftaccess features are mainly untested. Most of this man page is
|
||||
not finished. In particular, don't expect any feature to work that is
|
||||
used for anything else but authenticating a user logging in.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,293 @@
|
|||
$Id: eftd,v 1.1 1999/06/30 16:51:05 he Exp $
|
||||
|
||||
Sorry, rather incomplete and not in man page format.
|
||||
|
||||
But feel free to submit patches :-)
|
||||
|
||||
|
||||
eftd: eftp4linux EUROFILE transfer server.
|
||||
|
||||
eftd allows clients to connect to your machine via the ISDN and to
|
||||
transfer files by means of the EUROFILE transfer protocol. That
|
||||
protocol is specified by ETSI norms ETS 300-075 and ETS 300-383.
|
||||
|
||||
Unless the -s option is given, the server loops forever waiting for
|
||||
incoming connections and forks a child process for each connection
|
||||
received.
|
||||
|
||||
|
||||
Synopsis:
|
||||
|
||||
As this is alpha test software, options might change with each release!
|
||||
|
||||
eftd [-a [ACCESS_FILE]] [-IlsV?] [-d LEVEL] [-D MASK]
|
||||
[-b LOGFILE] [-l LEVEL] [-L MASK]
|
||||
[-U FALLBACK_USER_ID] [-x ADDR]
|
||||
|
||||
OPTIONS
|
||||
|
||||
-a Expects a string argument interpreted as a file name.
|
||||
If eftd is compiled with the CONFIG_EFTD_WUAUTH
|
||||
option, eftd reads ACCESS_FILE and uses the contents
|
||||
for user authentication similarly to wu-ftpd's
|
||||
ftpaccess file. See eftaccess(5) for further details.
|
||||
|
||||
-b Expects a string argument interpreted as a file name.
|
||||
Communication events selected by the -l or -L option
|
||||
are logged (appended) to the file specified by the
|
||||
option's argument. (This is the 'LogBook' file in
|
||||
terms of ETS 300 383, thus the 'b'). If this option is
|
||||
omitted, a system dependent default (i.e.
|
||||
/var/log/eftd.log) is used. Opening of the LogBook
|
||||
file can be supressed simply by not suppling any -l or
|
||||
-L option.
|
||||
|
||||
-d Expects an integer argument which is interpreted as a
|
||||
log level. Protocol or internal events up to the level
|
||||
are logged to stderr.
|
||||
|
||||
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.
|
||||
|
||||
-D The bitmask argument allows for low level grained
|
||||
control of stderr output. It overrides previous
|
||||
-I and augments -d options. For maximum amount of
|
||||
debugging output use "-D -1". As this is really
|
||||
intended to be used for low level debugging, examine
|
||||
the eftp4linux sources (start by reading the source
|
||||
file src/lib/tdu_user.h) if you really want to use
|
||||
this option on your own.
|
||||
|
||||
-I Logs the contents of /dev/isdnctrl to stderr. For this
|
||||
to work, other processes reading /dev/isdnctrl (i.e.
|
||||
isdnlog) should be stopped before). This option is
|
||||
intended for debugging purpose only.
|
||||
|
||||
-l The integer argument specifies the log level for
|
||||
selecting the events written to the LogBook file
|
||||
(as specified by the -b option). Levels are
|
||||
|
||||
0 No events at all.
|
||||
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.
|
||||
|
||||
CAUTION: this log feature is currently new, extremly
|
||||
unfinished, incomplete and subject to improvements
|
||||
(volunteers welcome) and not my highest priority item.
|
||||
Thus, don't expect the current format of the messages
|
||||
to be fixed forever.
|
||||
|
||||
-L Conceptually similar to -D (see the latter). Allows
|
||||
fine grained control for selecting the events logged
|
||||
to the LogBook (-b) file.
|
||||
|
||||
-x The string type argument should consist of up to 15
|
||||
digits which specify the X.25 [X.121/X.301] address
|
||||
the servers listens on for incoming connections. As
|
||||
EUROFILE is usually used with ISO-8208 X.25 DTE-DTE
|
||||
mode, you should use the empty string as argument
|
||||
here, which is the default. Thus, it is extremely
|
||||
unlikely that you want to use this option at all.
|
||||
|
||||
This option can be given two times, allowing the
|
||||
server to listen on two different x25 addresses
|
||||
simultaneously.
|
||||
|
||||
-s Single process mode. If this option is given, the
|
||||
server just serves the first incoming connection and
|
||||
exits when the session is finished. It does not fork a
|
||||
child process for serving that connection.
|
||||
|
||||
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.
|
||||
|
||||
-m Multiple connection mode. If this option is given, the
|
||||
server immidiately continues to accept new connections
|
||||
without waiting for the just accepted session to finish.
|
||||
The number of simultaneous served connections is not
|
||||
internally limited by the server. However, upper
|
||||
limits might be imposed by the mumber of physically
|
||||
available isdn B-channels, the number of running
|
||||
incoming isdn network interfaces configured with
|
||||
"encap x25iface", or by the authentification procedure
|
||||
(i.e. group limits configured in /etc/isdn/eftaccess).
|
||||
|
||||
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.
|
||||
|
||||
-U USER When this option is specified, a login attempt
|
||||
with a user name not in the passwd database will
|
||||
be using USER as the login name (with empty password).
|
||||
|
||||
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.
|
||||
|
||||
-V Prints version.
|
||||
|
||||
-? prints usage message.
|
||||
|
||||
FEATURES
|
||||
|
||||
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 eftd.sh
|
||||
shell script:
|
||||
|
||||
eftd.sh 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).
|
||||
|
||||
|
||||
TRANSFER NAMES
|
||||
|
||||
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 '(', ')', '*',
|
||||
'+', and '/'. The total length of the transfer name must not exceed 70
|
||||
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.
|
||||
|
||||
|
||||
TRANSFER NAME MAPPING
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
EVENT LOGGING
|
||||
|
||||
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.
|
||||
|
||||
|
||||
INTERWORKING PROBLEMS
|
||||
|
||||
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.
|
||||
|
||||
|
||||
RESTRICTIONS (also called BUGS :-)
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,25 @@
|
|||
.\" $Id: efthosts.5,v 1.1 1999/06/30 16:51:06 he Exp $
|
||||
.\" SCCSID: @(#)$Original-Id: ftphosts.5,v 1.2 1997/01/10 06:27:02 sob Exp $
|
||||
.\" based on ftphosts.5 1.2 1/26/93
|
||||
.\"
|
||||
.TH ftphosts 5
|
||||
.SH Name
|
||||
ftphosts \- ftpd individual user host access file
|
||||
.SH Description
|
||||
The ftphosts file is used to allow or deny access to certain
|
||||
accounts from various hosts.
|
||||
.SH Access Capabilities
|
||||
.TP 0.5i
|
||||
.B allow <username> <addrglob> [<addrglob> ...]
|
||||
Only allow host(s) matching <addrglob> to log in as <username>.
|
||||
.TP 0.5i
|
||||
.B deny <username> <addrglob> [<addrglob> ...]
|
||||
Always deny host(s) matching <addrglob> to log in as <username>.
|
||||
.SH Files
|
||||
FTPLIB/ftphosts
|
||||
.SH See Also
|
||||
.BR ftpd(8) ,
|
||||
.BR ftpaccess(5) ,
|
||||
.BR ftplog(5) ,
|
||||
.BR ftpconversions(5) ,
|
||||
.BR ftpshut(8)
|
||||
|
|
@ -0,0 +1,261 @@
|
|||
$Id: eftp,v 1.1 1999/06/30 16:51:06 he Exp $
|
||||
|
||||
Sorry, rather incomplete and not in man page format.
|
||||
|
||||
But feel free to submit patches :-)
|
||||
|
||||
|
||||
eftp is a simple EUROFILE transfer client with a command line user
|
||||
interface roughly resembling the ftp client.
|
||||
|
||||
Synopsis:
|
||||
|
||||
eftp should currently not be invoked directly be the user but by means of
|
||||
the eftp.sh shell script:
|
||||
|
||||
eftp.sh ISDN_NUMBER [ID]
|
||||
|
||||
where ISDN_NUMBER is the isdn number of the peer server to connect to.
|
||||
ID is usually entered as USER or USER/PASSWD, consisting of the
|
||||
userid and the password on the remote EUROFILE server.
|
||||
|
||||
Future versions of eftp will support the following command line
|
||||
options:
|
||||
|
||||
-i ISDN_NO
|
||||
specify the isdn no of the remote EUROFILE
|
||||
server to connect to. The server will try to
|
||||
set up an isdn connection to this number and
|
||||
an X.25 DTE-DTE connection on top of this.
|
||||
|
||||
-x X.25_ADDRESS
|
||||
directly specify the X.25 address used for
|
||||
setting up the X.25 connection. For eftp to
|
||||
work, an X.25 route for that address must
|
||||
already be present. The X.25 route must point
|
||||
to an isdn4linux network interface that is
|
||||
configured for outgoing connections to a
|
||||
destination EUROFILE server. The encapsulation
|
||||
of the interface must be "x25iface".
|
||||
|
||||
-u USER[/PASSWORD]
|
||||
The user identity used to login to the
|
||||
remote EUROFILE server. The password can
|
||||
be appended to the user id seperated by a
|
||||
'/' character. If no '/' is present in the
|
||||
paramater of the -u option, eftp will prompt
|
||||
for a password.
|
||||
|
||||
CAUTION:
|
||||
|
||||
Entering the password on the command line allows other users
|
||||
to spoof the password, i.e. by means of the ps command. The
|
||||
password might also leave other traces, i.e. in your shell's
|
||||
history file. Thus, DON'T include the passwd in the -u argument
|
||||
on machines where this is a concern (i.e. when untrusted users
|
||||
have shell accounts on the machine).
|
||||
|
||||
If the -u option is missing, the client will
|
||||
try to login without a user id (some servers
|
||||
will treat this as anonymous access).
|
||||
|
||||
-p suppress prompting for a password even if the
|
||||
argument to the -u option does not contain a
|
||||
password. This is useful for accounts on
|
||||
EUROFILE servers without password protection.
|
||||
|
||||
-h print a help message to stdout.
|
||||
|
||||
|
||||
|
||||
In order to set up isdn4linux network interfaces, the eftp.sh script
|
||||
needs to be called from the root user. Before the eftp program itself
|
||||
is executed, the userid is switched (configurable in the
|
||||
/etc/isdn/eft.conf file) and the working directory is changed to /tmp.
|
||||
(This is an interim measure and will be fixed in a future release).
|
||||
If ISDN_NUMBER is the string "localhost", the eftp.sh scripts tries
|
||||
to set up a connection to the own computer by means of the isdnloop
|
||||
driver, for the benefit of your phone bill.
|
||||
|
||||
When eftp has established the connection, it issues the "eftp>" prompt
|
||||
and waits for commands that will be read from standard input.
|
||||
If configured before compilation, interactive input can be edited by
|
||||
means of the GNU readline library.
|
||||
|
||||
The following commands are recognised:
|
||||
|
||||
|
||||
|
||||
Commands for Listing and Transferring Files
|
||||
|
||||
|
||||
dir [PATTERN]
|
||||
|
||||
This corresponds to ETS 300-075 and ETS 300-383 T-DIRECTORY
|
||||
primitive. It prints a list of files contained in the current
|
||||
working directory (ETSI calls it the "current filestore").
|
||||
PATTERN is a pattern as defined in ETS 300-075 and selects a
|
||||
subset of those files to be displayed. ETS 300-075 pattern are
|
||||
different from shell wildcard or regular expressions, but the
|
||||
pattern "*" matches all filenames as you'd expect. I won't
|
||||
explain further pattern rules here because most servers don't
|
||||
recognise any patterns different from "*" anyway.
|
||||
|
||||
If pattern is omitted, the * pattern is assumed.
|
||||
|
||||
Pattern applies to the EUROFILE transfer name of the files,
|
||||
which is not necessarily identical to the filename itself.
|
||||
|
||||
Likewise, the output of the command does not list the
|
||||
filenames, but the transfer names of the files and the file
|
||||
length. Note that only regular files are listed. For listing
|
||||
subdirectories, there are the list and slist commands.
|
||||
|
||||
|
||||
xdir [PATTERN]
|
||||
|
||||
This is similar to the dir command but requests the directory
|
||||
contents in extended format. In addition to the transfer name,
|
||||
this will also contain the real name of the file and the time
|
||||
stamp of the last write access.
|
||||
|
||||
Note that not all servers support directory requests with
|
||||
extended format. Some of those servers will respond with
|
||||
a normal directory contents file, others will reject the
|
||||
request. In the former case, eftp will issue a warning message
|
||||
and use the transfer name for the file name and use 1970-01-01
|
||||
as the last access date. (The eftp4linux server supports
|
||||
extended directory formats).
|
||||
|
||||
|
||||
get TRANSFER_NAME [PATH_NAME]
|
||||
|
||||
This corresponds to the 300-075 T-LOAD primitive and
|
||||
tries to load the file identified by TRANSFER_NAME
|
||||
from the remote server and stores it locally using PATH_NAME
|
||||
as the destination. If PATH_NAME is omitted, TRANSFER_NAME is
|
||||
also used as the destination name.
|
||||
|
||||
|
||||
put [PATH_NAME] TRANSFER_NAME
|
||||
|
||||
This corresponds to the ETS 300-075 T-SAVE primitive and
|
||||
tries to upload the local file identified by PATH_NAME
|
||||
to the remote server, using TRANSFER_NAME as the destination.
|
||||
If PATH_NAME is omitted, TRANSFER_NAME is also used as to
|
||||
identify the local file.
|
||||
|
||||
mget PATTERN
|
||||
|
||||
get multiple files whose transfer names match PATTERN. PATTERN
|
||||
is (currently) interpreted a shell glob pattern, not an
|
||||
ETS 300 075 pattern.
|
||||
|
||||
mput PATTERN
|
||||
|
||||
put multiple files whose names match PATTERN. PATTERN is
|
||||
interpreted a shell glob pattern, not an ETS 300 075 pattern.
|
||||
|
||||
NOTE: The matched name is also used as the transfer name.
|
||||
If pattern matched local files whose file name do not form
|
||||
a valid ETS 300-383 transfer name, the transfer of those
|
||||
files might fail.
|
||||
|
||||
prompt [on|off]
|
||||
|
||||
If "on", prior to each file transferred by mput or mget, the
|
||||
user is prompted for confirmation. If no parameter is given
|
||||
the on/off value is toggled.
|
||||
|
||||
Possible user responses to the prompt:
|
||||
|
||||
y transfer the file
|
||||
n don't transfer the file and prompt for the next one
|
||||
|
||||
case [on|off]
|
||||
|
||||
If "off", cases are ignored when matching PATTERN in mget and mput.
|
||||
If parameter is missing, toggle current parameter value.
|
||||
|
||||
This currently does nor work with all versions of libc.
|
||||
|
||||
|
||||
Navigation Commands (related to directories)
|
||||
|
||||
These commands are likely to fail because many servers don't
|
||||
support the navigation facility. (The eftp4linux server,
|
||||
however, supports this :-)
|
||||
|
||||
cd [DIRECTORY]
|
||||
|
||||
This changes the current working directory ("current
|
||||
filestore") to DIRECTORY. If DIRECTORY is omitted,
|
||||
the default directory (this is the one initially entered
|
||||
when logged in) is changed to.
|
||||
|
||||
This command is likely to fail because many servers don't
|
||||
support the navigation facility.
|
||||
|
||||
pwd
|
||||
|
||||
This prints the name of the server's current working directory
|
||||
("current filestore") to stdout.
|
||||
|
||||
slist
|
||||
|
||||
This corresponds to the 300-383 S-LIST primitive.
|
||||
It prints a list of the subdirectories contained in the
|
||||
current working directory. The list items consist of
|
||||
a so called file store reference followed by the filestore
|
||||
(directory) name. (The eftp4linux server supports this, but
|
||||
the filestore references are currently not generated totally
|
||||
norm conforming.)
|
||||
|
||||
|
||||
list
|
||||
|
||||
This corresponds to the ETS 300-383 LIST primitive.
|
||||
It is similar to the slist command, but prints a list of all
|
||||
directories of the server. (Even the eftp4linux server does not
|
||||
support this).
|
||||
|
||||
|
||||
|
||||
Misc Commands
|
||||
|
||||
msg MESSAGE
|
||||
|
||||
The MESSAGE string is send literally to the remote server
|
||||
if the server supports it (most servers won't) by means of
|
||||
the ETS 300-075 T-TYPED_DATA primitive.
|
||||
|
||||
If MESSAGE is ommitted, the client will prompt for the message
|
||||
string (can currently cause problems as protocol precessing is
|
||||
currently not performed whil waiting for the user input).
|
||||
|
||||
lcd DIR
|
||||
|
||||
change local working directory to DIR
|
||||
|
||||
! COMMAND-STRING
|
||||
|
||||
execute COMMAND-STRING as a shell command.
|
||||
|
||||
quit
|
||||
|
||||
This will quit the EUROFILE session, close the connection, and
|
||||
exit the eftp programme.
|
||||
|
||||
|
||||
Readline Support
|
||||
================
|
||||
|
||||
When eftp is compiled with the CONFIG_EFTP_READLINE option set to "y"
|
||||
in the configure shell script, command line editing is performed by
|
||||
means of the readline library. (Thanks to Michael Mauch for adding
|
||||
this).
|
||||
|
||||
When using the readline code, the terminal might be left in a strange
|
||||
mode if the program didn't exit properly. In such a case you can
|
||||
return to the normal terminal mode by running the program "reset",
|
||||
which is a link to "tset" (see tset(1)).
|
||||
Loading…
Reference in New Issue