Impossible de connecter à ftp

Asked by robert leleu

Grâce à la question "cannot do ftp backup" j'ai installé 0.2.0 beta5
et, common, gtk, ftp, ssh

J'ai préparé un répertoire accessible par ftp, que je vois effectivement avec nautilus, sous le nom de
ftp://tux@serveur:22/
il n'y a pas de mot de passe, car je suis sur une installation domestique.

quand je copie colle cette destination dans le champ de répertoire distant et que je teste j'ai l'erreur:
Error matching the schema 'ftp://user:pass@server/anything' with 'ftp://tux@serveur:22/' (The '/' after server is mandatory)

Question information

Language:
French Edit question
Status:
Solved
For:
nssbackup Edit question
Assignee:
No assignee Edit question
Solved by:
Jean-Peer Lorenz
Solved:
Last query:
Last reply:
Revision history for this message
Best Jean-Peer Lorenz (peer.loz) said :
#1

Hello Robert,

since I don't speak french, I can only guess what your question is. However, I'll try to answer what I've understood:

You cannot connect to the remote ftp site because you use an adress schema that does not match the schema assumed by the developers. I would not call it a bug, but a missing feature.

Currently only ftp adresses that matches EXACTLY the schema 'ftp://user:pass@server/anything' are supported. The adress that you use cannot be parsed for several reasons:

* you use a username without a password
* you specify a port after the server delimited by a ':'. This is used to separate the username and the password in the original schema

I've got problems while trying to connect to a remote site with the following adress schema:
'ftp://my_name@my_university:pass@my_university/my_remote_folder'.
Here the problem is the multiple occurence of the '@' token.

As you can see, the use of remote sites is quite half-baked. Due to the explanations above, it is not possible to use a ftp site with your described adress schema, at the moment.

For me (in my development branch) I've fixed the mentioned issue and I'll try to fix your problem too and release it in version 0.2.

Thanks a lot for using NSsbackup.

Best regards.
Jean-Peer

Revision history for this message
robert leleu (robert-jean-leleu) said :
#2

So fast an answer! You guessed perfectly the french...
I changed the ftp configuration to port 21 and used a password.

So I got the connexion using the scheme you provided.

In case you need translation from french, spanish and esperanto, just send me the message....

Thanks to you for putting NSbackup available

Revision history for this message
robert leleu (robert-jean-leleu) said :
#3

I had some success...but none backup.

The backup directory ftp://tux:keynux@serveur/ is correctly tested from NSsbackup configure gui
I am able to write in as root or user (I put an empty file in), and I can access it from a nautilus bookmark whose aim is ftp://tux@serveur/
I prepared a test profile with just one small file to backup, and activated Backup now

I received a log, pasted at the end of this message, but the backup repertory remains empty, except for the empty file I put in.
I found a /mnt/sbackup repertory, empty, there is not even the empty file I created....

NSSBackup 'Default Profile' Logger
==============
2008-12-12 12:05:14,829 - DEBUG - ConfigManager.py:validateConfigFileOpts(421) - Validating config file
2008-12-12 12:05:14,829 - INFO - ConfigManager.py:__init__(269) - ConfigManager created with '/etc/nssbackup.conf'
2008-12-12 12:05:14,830 - INFO - BackupManager.py:__init__(71) - Création du BackupManager
2008-12-12 12:05:15,102 - INFO - BackupManager.py:makeBackup(90) - Début de la sauvegarde
2008-12-12 12:05:15,103 - DEBUG - BackupManager.py:__setlockfile(380) - Created lockfile at '/var/lock/sbackup.lock' with info '6859'
2008-12-12 12:05:15,103 - INFO - BackupManager.py:makeBackup(95) - Initialisation de FUSE FILE ACCESS MANAGER
2008-12-12 12:05:15,430 - INFO - BackupManager.py:__checkTarget(419) - Création du répertoire cible '/mnt/sbackup/ftp_tux@serveur/'

Revision history for this message
Jean-Peer Lorenz (peer.loz) said :
#4

Do you have the package 'curlftpfs' installed?

For your information: In my tests I was not able to use an ftp site as superuser, too. This is apparently related to the behaviour of curlftpfs. It allows only the user that calls curlftpfs to access the mounted directory. I'm working on a fix for this but it is not finished so far and needs some testing.

Please re-test your configuration as non-root user and post your results.

Revision history for this message
robert leleu (robert-jean-leleu) said :
#5

Thaks for your analysis of the included results of my new test:

Curlftpfs is installed, last version, 0.9.2-1
I made my NSsbackup tests as user, and herebelow you'll find the log of a fresh one, and the content of nssbackup.conf. The FTPserver of the receiving machine did see the connexion:
15:13:18] - [1] Connect to 192.168.1.11. Get Username.

[15:13:18] - [1] User TUX Connected

[15:13:18] - [1] TUX: Current Directory: D:\sauvesurd\

I clicked on Backup now at 15:15, it created a python task 22921, (The task stayed visible (as zombie) in the system reporter, and disappeared as I closed the NSsbackup config gui) and I received an automated mail including:

NSSBackup 'Default Profile' Logger
==============
2008-12-13 15:15:22,357 - DEBUG - ConfigManager.py:validateConfigFileOpts(421) - Validating config file
2008-12-13 15:15:22,358 - INFO - ConfigManager.py:__init__(269) - ConfigManager created with '/etc/nssbackup.conf'
2008-12-13 15:15:22,360 - INFO - BackupManager.py:__init__(71) - Création du BackupManager
2008-12-13 15:15:22,456 - WARNING - BackupManager.py:makeBackup(87) - Launch helper exited with unknown return code 1
2008-12-13 15:15:22,458 - INFO - BackupManager.py:makeBackup(90) - Début de la sauvegarde
2008-12-13 15:15:22,459 - DEBUG - BackupManager.py:__setlockfile(380) - Created lockfile at '/var/lock/sbackup.lock' with info '22921'
2008-12-13 15:15:22,460 - INFO - BackupManager.py:makeBackup(95) - Initialisation de FUSE FILE ACCESS MANAGER
2008-12-13 15:15:22,722 - INFO - BackupManager.py:__checkTarget(419) - Création du répertoire cible '/mnt/sbackup/ftp_tux@serveur/'

[log]
file = /var/log/nssbackup.log
level = 10

[places]

[schedule]
anacron = daily

[dirconfig]
/proc/ = 0
/sys/ = 0
/var/cache/ = 0
/tmp/ = 0
/dev/ = 0
/home/tux/Documents/adresse.doc = 1
/var/tmp/ = 0

[general]
splitsize = 0
target = ftp://tux:keynux@serveur/
run4others = 1
format = gzip
mountdir = /mnt/sbackup/
maxincrement = 21
lockfile = /var/lock/sbackup.lock

Revision history for this message
Jean-Peer Lorenz (peer.loz) said :
#6

I did some further tests and figured out that the above issue not holds for non-root users. Nevertheless I experienced some problems due to 'chmod' operations on ftp servers (the one I use doesn't support 'chmod'). To catch the problem please describe your configuration (what is backup source, what is the destination etc.), perform a backup and post the full logfile here. Can you test the remote site sucessful in the config-gui?

Regards. Jean-Peer.

Revision history for this message
robert leleu (robert-jean-leleu) said :
#7

here the requested informations

backup source is a file in my home repertory under Ubuntu.
destination is on a win98 computer, accessed through ftp
The log given in the previous post is the whole content of the log file, written in response to a "backup now"
The remote site is successfully tested in the config-gui

Did you notice the warning line in this log? I don't understand what it means, I can just tell that my python is 2.5.2

May I add, about the log line
 2008-12-13 15:15:22,459 - DEBUG - BackupManager.py:__setlockfile(380) - Created lockfile at '/var/lock/sbackup.lock' with info '22921'

that I just checked (during a new test) that in fact no lockfile is created, the /var/lock/ repertory is empty; this repertory is property of root.....which seems however correct since the gui invoke sudo when opening (and ask for the password)

hoping that this will give you some clues.

Revision history for this message
robert leleu (robert-jean-leleu) said :
#8

complementary informations/

Herbelow the log of the recent test made to see if any lockfile is made. This log does not show the warning line

And at the time I find in /mnt an empty nssbackup repertory created at 20:59 (and not a sbackup, as stated in the log), and an old empty sbackup repertory, from dec 12 12:05, presumably from previous use of sbackup....

Should I delete these before a new test?

NSSBackup 'Default Profile' Logger

==============

2008-12-14 20:59:23,168 - DEBUG - ConfigManager.py:validateConfigFileOpts(421) - Validating config file
2008-12-14 20:59:23,169 - INFO - ConfigManager.py:__init__(269) - ConfigManager created with '/etc/nssbackup.conf'
2008-12-14 20:59:23,170 - INFO - BackupManager.py:__init__(71) - Création du BackupManager
2008-12-14 20:59:23,554 - INFO - BackupManager.py:makeBackup(90) - Début de la sauvegarde
2008-12-14 20:59:23,555 - DEBUG - BackupManager.py:__setlockfile(380) - Created lockfile at '/var/lock/sbackup.lock' with info '11509'
2008-12-14 20:59:23,556 - INFO - BackupManager.py:makeBackup(95) - Initialisation de FUSE FILE ACCESS MANAGER
2008-12-14 20:59:23,677 - INFO - BackupManager.py:__checkTarget(419) - Création du répertoire cible '/mnt/sbackup/ftp_tux@serveur/'

Revision history for this message
robert leleu (robert-jean-leleu) said :
#9

So I just checked again:

1/ testing the destination from the gui: success. Indeed in the log window of the server appears:

[15:50:42] - [4] Connect to 192.168.1.11. Get Username.

[15:50:42] - [4] User TUX Connected

[15:50:42] - [4] TUX: Current Directory: D:\sauvesurd\

[15:50:42] - [4] TUX: Create Directory: D:\sauvesurd\testFuseFam

[15:50:42] - [4] TUX: Directory Deleted: D:\sauvesurd\testFuseFam

[15:50:42] - [4] Client TUX, 192.168.1.11 Disconnected (00:00:00 Min)

and a nssbackup empty directory is created in /mnt

there is no log from nssbackup

2/ clicking Backup now
there is a connexion to the ftp server, seen by it as
[15:56:30] - [5] Connect to 192.168.1.11. Get Username.

[15:56:30] - [5] User TUX Connected

[15:56:30] - [5] TUX: Current Directory: D:\sauvesurd\

and it stays, waiting,
No repertory is created on the server.

a log is created by NSSbackup (see below)
but no /var/lock/sbackup.lock is created
although a /mnt/sbackup/ directory is created, empty
with info '25022' corresponds to the number of a python task (just python with no further indication), which stays as zombie until the NSSbackup is closed.

NSSBackup 'Default Profile' Logger
==============
2008-12-15 15:58:34,803 - DEBUG - ConfigManager.py:validateConfigFileOpts(421) - Validating config file
2008-12-15 15:58:34,807 - INFO - ConfigManager.py:__init__(269) - ConfigManager created with '/etc/nssbackup.conf'
2008-12-15 15:58:34,808 - INFO - BackupManager.py:__init__(71) - Création du BackupManager
2008-12-15 15:58:35,160 - INFO - BackupManager.py:makeBackup(90) - Début de la sauvegarde
2008-12-15 15:58:35,160 - DEBUG - BackupManager.py:__setlockfile(380) - Created lockfile at '/var/lock/sbackup.lock' with info '25022'
2008-12-15 15:58:35,161 - INFO - BackupManager.py:makeBackup(95) - Initialisation de FUSE FILE ACCESS MANAGER
2008-12-15 15:58:35,338 - INFO - BackupManager.py:__checkTarget(419) - Création du répertoire cible '/mnt/sbackup/ftp_tux@serveur/'

Revision history for this message
robert leleu (robert-jean-leleu) said :
#10

Waiting for further instructions..if any is possible, I made a test, backing up on the same hard disk, and it worked perfect.

So I would appreciate that you let me know if I have to wait for some debugging or if I just made some error.

Thanks.

Revision history for this message
Jean-Peer Lorenz (peer.loz) said :
#11

I just finished working on some fixes und uploaded these to the development branch. Unfortenately I'm not finished with packaging till now so I cannot provide a new release download RC2 today. I'll give my very best to provide a download containing the latest fixes, but I cannot appoint to any fixed date. Please check out the announcements and repeat your tests with this latest code as soon as a download is available.

When testing, please make sure to use debug output level within your profile. I fixed, among other things, some issues related to log outputs - so I'm confident we're able to find the error (if there's one).

Best regards. Jean-Peer.