[sword-devel] non-anonymous repository use

Karl Kleinpaste karl at kleinpaste.org
Sun May 24 19:58:52 MST 2009


I wanted to experiment with non-anonymous module management.  So I
turned on FTP, defined myself a new source, and got very confused.

What I'm up against may be a curl issue, that is, it may not be Sword's
fault.  But it sure does look funny.

I wanted merely to expose my own module set redundantly, that is,
/home/karl/.sword -- seemed like an obvious thing to try.  When I
created a source that appeared obvious in that sense, it didn't give me
what I expected.

    FTPSource=Karl|127.0.0.1|/home/karl/.sword|karl|XXXX|

The problem is that curl seems unprepared for the fact that it starts
out in /home/karl when logging in as myself:

    ***** sourceURL: ftp://127.0.0.1/home/karl/.sword/mods.d/ 
    CURLFTPTransport: TEXT: About to connect() to 127.0.0.1 port 21 (#0)
    CURLFTPTransport: TEXT:   Trying 127.0.0.1... 
    CURLFTPTransport: TEXT: connected
    CURLFTPTransport: TEXT: Connected to 127.0.0.1 (127.0.0.1) port 21 (#0)
    CURLFTPTransport: <= Recv header: 220 (vsFTPd 2.0.7)
    CURLFTPTransport: => Send header: USER karl
    CURLFTPTransport: <= Recv header: 331 Please specify the password.
    CURLFTPTransport: => Send header: PASS XXXX
    CURLFTPTransport: <= Recv header: 230 Login successful.
    CURLFTPTransport: => Send header: PWD
    CURLFTPTransport: <= Recv header: 257 "/home/karl"
    CURLFTPTransport: TEXT: Entry path is '/home/karl'
>>> CURLFTPTransport: => Send header: CWD home
>>> CURLFTPTransport: <= Recv header: 550 Failed to change directory.
    CURLFTPTransport: TEXT: Server denied you to change to the given directory
    CURLFTPTransport: TEXT: Connection #0 to host 127.0.0.1 left intact
    CURLFTPTransport: TEXT: Access denied to remote resource

curl is assuming that it begins in /, and so it believes in turn that it
should be able to traverse straight down through the directory hierarchy
from the root directory -- not so, when logging as someone other than
the anon user.

With this thought in mind, I have to wonder why curl bothers to PWD, if
it can't put the answer to use.

When I modified the entry slightly, I got an even more confused instance
of the same problem.

    FTPSource=Karl|127.0.0.1|.sword|karl|XXXX|

Note lack of any '/'.

>>> ***** sourceURL: ftp://127.0.0.1.sword/mods.d.tar.gz 
    CURLFTPTransport: TEXT: getaddrinfo(3) failed for 127.0.0.1.sword:21
>>> CURLFTPTransport: TEXT: Couldn't resolve host '127.0.0.1.sword'
    CURLFTPTransport: TEXT: Closing connection #0
    CURLFTPTransport: TEXT: Couldn't resolve host name

What I'm left with is treating ~karl as though it were a filesystem
root, which is pretty much nonsense, but it fits into curl's mistaken
absolutist psychosis:

    FTPSource=Karl|127.0.0.1|/.sword|karl|XXXX|

Note slightly absurd-looking anchoring '/' on path.

    ***** sourceURL: ftp://127.0.0.1/.sword/mods.d.tar.gz 
    CURLFTPTransport: TEXT: About to connect() to 127.0.0.1 port 21 (#0)
    CURLFTPTransport: TEXT:   Trying 127.0.0.1... 
    CURLFTPTransport: TEXT: connected
    CURLFTPTransport: TEXT: Connected to 127.0.0.1 (127.0.0.1) port 21 (#0)
    CURLFTPTransport: <= Recv header: 220 (vsFTPd 2.0.7)
    CURLFTPTransport: => Send header: USER karl
    CURLFTPTransport: <= Recv header: 331 Please specify the password.
    CURLFTPTransport: => Send header: PASS XXXX
    CURLFTPTransport: <= Recv header: 230 Login successful.
    CURLFTPTransport: => Send header: PWD
    CURLFTPTransport: <= Recv header: 257 "/home/karl"
    CURLFTPTransport: TEXT: Entry path is '/home/karl'
>>> CURLFTPTransport: => Send header: CWD .sword
>>> CURLFTPTransport: <= Recv header: 250 Directory successfully changed.

and so forth.  After this psychosis-accommodating doodad was emplaced,
non-anon module management worked fine.

This makes the scheme work, but it surely seems Wrong.



More information about the sword-devel mailing list