• Mount the filesystem to your webserver
• FTP or SFTP to the remote box
• telnet / ssh to the remote box
• Use rsync to obtain the file listing
• Create your own protocol with daemon & client ;-)

You might also take a look at rcopy for some other ideas, which purports to mirror two servers together.

I did something similar, using a remote webserver's directory listing of files, and presenting them to my local machine as "local" files, for users to click/download/etc. Here's an example of that, using kernel.org in this case.

Basically what this does is fetch the remote "page" of files, extract the links, calculate the file sizes, "commify" them, and prints them out. Simple. Maybe this will give you a few ideas, depending on where/how these files are found.

use strict;
use LWP::UserAgent;
use HTML::LinkExtor;
use URI::URL qw(url);

my $url     = "http://kernel.org/pub/linux/kernel/v1.0/";

my $ua      = LWP::UserAgent->new;
$ua->agent('pps 0.1.43');
my @links   = ();

sub callback {
        my ($tag, %attr) = @_;
        return if $tag eq 'href';
        push(@links, values %attr);
        return (@links);
}

my $p       = HTML::LinkExtor->new(\&callback);
my $res     = $ua->request(
               HTTP::Request->new(GET => $url),
                       sub {$p->parse($_[0])});

my $base    = $res->base;
@links      = map {$_ = url($_, $base)->abs;} @links;
my @krn     = grep(/tar/, @links);

foreach my $krn (@krn) {
        my @remote_files = HTTP::Request->new(HEAD=>$krn);
        my $resp         = $ua->request(@remote_files);
        my $length       = $resp->header('Content-Length');

        my $bprecise     = sprintf "%.0f", $length;
        my $bsize        = insert_commas($bprecise);
        my $kprecise     = sprintf "%.0f", ($length/1024);
        my $ksize        = insert_commas($kprecise);

        my $archtype;    # tarball? or bzip2? or zip?
        my $krnhref      = substr($krn, 48, 70);

        if ($krn =~ /tar.gz/) {
                $archtype = "tarball";
        } elsif ($krn =~ /bz2/) {
                $archtype = "bzip";
        } else {
                $archtype = "zip";
        }
        print "Path: $krn\nFile: $krnhref ";
        print "($archtype) - ${ksize}kb, $bsize bytes\n\n";
}

sub insert_commas {   
        my $text = reverse $_[0];
        $text =~ s/(\d{3})(?=\d)(?!\d*\.)/$1,/g;
        return scalar reverse $text;
}
[download]

Personally, I'd go for NFS or samba, if that's in the realm of the possibilities.

Abigail

yeah I have access to both machines. The reason we need to develop this system is because we are not allowing any kind of ftp access to the live server, i'm not sure about sftp. We just connect using ssh and rsync. After giving it some thought I think I am going to get the file listing from machine a, then check the file exists on machine b by sending a http request for it via LWP. This should be ok because we will only need to list top level folders, so only make a few requests to check the folders exist.

This functionality is a bit limited, but it's enough to fulfill our requirements ;-)

Cheers,
Tom

Dunno all the whys and wherefores of not allowing remote FTP access to the system, but if you put a web server on the remote system and write a secure CGI, you can easily provide listings and downloads, perhaps by only allowing HTTP access from the machine that's currently serving up CGI (i.e. the one through which the users will access the site); even that's not necessary if you just give the web server access to the directories containing the files and let it list the files in the directories (this is very easy to do with Apache, for example).

Keeping it short and sweet, why not let HTTP be your remote file access protocol =)

If not P, what? Q maybe?
"Sidney Morgenbesser"

Reasons not to use FTP:

1. Sends passwords in plaintext
2. Multiple-port design is the cause of many headaches for firewall administrators
3. Generally considered insecure (though more for historical problems with server software than today's software)

Even if we accept that #3 is due to old and buggy software, #1 is reason enough to dump it. #2 isn't a big deal, since admins running firewalls tend to notice the problem the first week on the job and always keep it in mind from then on. However, it also is a problem for the firewall software itself (the early Linux 2.4 series packet filter had a bug where if you let FTP in, an attacker could get through any port).

Its not like there aren't better alterantives. In particular, the sftp subsystem that comes with OpenSSH is great. It's a one-line change to your sshd.config and works over the existing SSH port.

IMHO, HTTP is a poor subsitute for FTP, except as a quick-and-dirty document retrevial system. Uploading is hacked in, and its stateless nature has been the cause of hackery elsewhere.

----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer

Note: All code is untested, unless otherwise stated

If you have ssh already installed, then you can get sftp with a one-line change to sshd.config. Add this:

Subsystem sftp sftp-server
[download]

And then restart sshd.

----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer

Note: All code is untested, unless otherwise stated