Backup RC1 problem

[ssi.inc]

I am having an odd issue with backup.

This message shows up in the messaging system for admin every night. Sorry about the obfuscated user names. I don't think my users would appreciate me posting them on a public forum.

I'm using FTP as a backup path ftp=<ftp_backup_site_ip_address>

User admin has been backed up.
User <user1> has been backed up.
User <user2> has been backed up.
User <user3> has been backed up.
User <user4> has been backed up.
User <user5> has been backed up.
User <user6> has been backed up.
User <user7> has been backed up.
User <user8> has been backed up.

Warning: ftp_login(): User <ftp_backup_login_name> cannot log in, home directory inaccessible. in - on line 19
Inavalid login/password for <ftp_backup_login_name> on <ftp_backup_site_ip_address>
User <user9> has been backed up.

Warning: ftp_login(): User <ftp_backup_login_name> cannot log in, home directory inaccessible. in - on line 19
Inavalid login/password for <ftp_backup_login_name> on <ftp_backup_site_ip_address>
User <user8> has been backed up.

Warning: ftp_login(): User <ftp_backup_login_name> cannot log in, home directory inaccessible. in - on line 19
Inavalid login/password for <ftp_backup_login_name> on <ftp_backup_site_ip_address>
User <user8> has been backed up.

Warning: ftp_login(): User <ftp_backup_login_name> cannot log in, home directory inaccessible. in - on line 19
Inavalid login/password for <ftp_backup_login_name> on <ftp_backup_site_ip_address>
User <user8> has been backed up.

Warning: ftp_login(): User <ftp_backup_login_name> cannot log in, home directory inaccessible. in - on line 19
Inavalid login/password for <ftp_backup_login_name> on <ftp_backup_site_ip_address>
User <user8> has been backed up.


And etc...

the odd part is the first 9 times DirectAdmin uses the FTP path to copy the user backup it works just fine. But it always fails on the 10th user backup copy.

The warning it gives about “in – on line 19” up there could not be less clear. I have no idea what file it is referring to.

On the FTP server where the backup is supposed to be copied to the log looks like this:

#Software: Microsoft Internet Information Services 5.0
#Version: 1.0
#Date: 2007-06-21 11:57:10
#Fields: time c-ip cs-method cs-uri-stem sc-status
11:57:10 67.94.206.200 [233]USER <ftp_backup_login_name> 331
11:57:10 67.94.206.200 [233]PASS - 230
11:57:12 67.94.206.200 [233]created admin.root.admin.tar.gz 226
11:57:12 67.94.206.200 [233]QUIT - 226
11:57:53 67.94.206.200 [234]USER <ftp_backup_login_name> 331
11:57:53 67.94.206.200 [234]PASS - 230
11:58:02 67.94.206.200 [234]created user.admin.admin3.tar.gz 226
11:58:02 67.94.206.200 [234]QUIT - 226
11:58:24 67.94.206.200 [235]USER <ftp_backup_login_name> 331
11:58:24 67.94.206.200 [235]PASS - 230
11:58:29 67.94.206.200 [235]created user.admin.<user1>.tar.gz 226
11:58:29 67.94.206.200 [235]QUIT - 226
11:59:07 67.94.206.200 [236]USER <ftp_backup_login_name> 331
11:59:07 67.94.206.200 [236]PASS - 230
11:59:24 67.94.206.200 [236]created user.admin.<user2>.tar.gz 226
11:59:24 67.94.206.200 [236]QUIT - 226
11:59:24 67.94.206.200 [237]USER <ftp_backup_login_name> 331
11:59:24 67.94.206.200 [237]PASS - 230
11:59:24 67.94.206.200 [237]created user.admin.<user3>.tar.gz 226
11:59:24 67.94.206.200 [237]QUIT - 226
11:59:30 67.94.206.200 [238]USER <ftp_backup_login_name> 331
11:59:30 67.94.206.200 [238]PASS - 230
11:59:35 67.94.206.200 [238]created user.admin.<user4>.tar.gz 226
11:59:35 67.94.206.200 [238]QUIT - 226
11:59:40 67.94.206.200 [239]USER <ftp_backup_login_name> 331
11:59:40 67.94.206.200 [239]PASS - 230
11:59:43 67.94.206.200 [239]created user.admin.<user5>.tar.gz 226
11:59:43 67.94.206.200 [239]QUIT - 226
12:00:55 67.94.206.200 [240]USER <ftp_backup_login_name> 331
12:00:55 67.94.206.200 [240]PASS - 230
12:02:17 67.94.206.200 [240]created user.admin.<user6>.tar.gz 226
12:02:17 67.94.206.200 [240]QUIT - 226
12:02:36 67.94.206.200 [241]USER <ftp_backup_login_name> 331
12:02:42 67.94.206.200 [241]PASS - 530
12:02:42 67.94.206.200 [241]QUIT - 530
12:02:47 67.94.206.200 [242]USER <ftp_backup_login_name> 331
12:02:47 67.94.206.200 [242]PASS - 530
12:02:47 67.94.206.200 [242]QUIT - 530
12:03:01 67.94.206.200 [243]USER <ftp_backup_login_name> 331
12:03:01 67.94.206.200 [243]PASS - 530
12:03:01 67.94.206.200 [243]QUIT - 530
12:03:04 67.94.206.200 [244]USER <ftp_backup_login_name> 331
12:03:04 67.94.206.200 [244]PASS - 530
12:03:04 67.94.206.200 [244]QUIT - 530
12:03:04 67.94.206.200 [245]USER <ftp_backup_login_name> 331
12:03:04 67.94.206.200 [245]PASS - 530
12:03:04 67.94.206.200 [245]QUIT - 530
12:04:04 67.94.206.200 [246]USER <ftp_backup_login_name> 331
12:04:04 67.94.206.200 [246]PASS - 530
12:04:04 67.94.206.200 [246]QUIT - 530


Yes, it's Microsoft server, IIS. So sue me... you gotta give your customer's what they want.

Anyways... I can not make heads or tails of this problem. I understand that this backup feature is only RC1, and don't rely on it as my sole backup, I just thought I might toss this out there and see what y'all thought. My fault, did I misconfigure something? Or is this a known bug with the backup app?
If the DirectAdmin people wander by this and ask, I'd be more than happy to email y'all the non-obfuscated log files.

 

[ssi.inc]

Found a solution

Well no one seems to be terribly interested in this problem.

The problems seems to be with the anti-virus software on the destination FTP server. Adding GZIP files to it's exclude list solved the problem.

A quick scan of the GZIP files shows some .phishing viruses. Curious, I thought ClamAV was supposed to catch all those. I guess you get what you pay for.

 

[nobaloney]

Well no one seems to be terribly interested in this problem.

I think you're right that no one seems terribly interested in trying to understand how your Windows server operates.

The problems seems to be with the anti-virus software on the destination FTP server. Adding GZIP files to it's exclude list solved the problem.

And it appears we were right; the problem was with proprietary software on your Windows system.

A quick scan of the GZIP files shows some .phishing viruses. Curious, I thought ClamAV was supposed to catch all those. I guess you get what you pay for.

While ClamAV is NOT a part of DirectAdmin, I think, nevertheless, this is a good area to understand better.

How did those GZIP files end up on your DA server? Did you set up ClamAV on your server to check all files, or (as most of us do) only incoming emails?

And were those GZIPped files from email files?

Jeff

 

[ssi.inc]

I think you're right that no one seems terribly interested in trying to understand how your Windows server operates.

And it appears we were right; the problem was with proprietary software on your Windows system.

How did those GZIP files end up on your DA server? Did you set up ClamAV on your server to check all files, or (as most of us do) only incoming emails?

And were those GZIPped files from email files?

Jeff

I can't be the only admin using a mixed network. I would think someone has seen a similar issue and could comment as such.

I think there is a rather obvious problem with the Backup RC1 component of DirectAdmin. The only thing that ends up in the DirectAdmin backup log is:

"Warning: ftp_login(): User cannot log in, home directory inaccessible. in - on line 19"

That particular line is less than helpful. 1.) User cannot log in; seems pretty obvious. 2.) Home directory inaccessible; umm... no, the user can get to /home/<username> just fine. 3.) in - on line 19; i don't think that's even English. Line 19 of what? in - ? what does the "-" mean?

Something is wrong with the way this particular error gets logged! As it is currently logged I am going to blame the Linux system first, not the windows system, because the Linux system seems to be telling me that the User's home directory is inaccessible, and it doesn't even say which files/script/whatever this mythical "line 19" is in.

I guess for those that don't know, the GZIP files come from the Backup RC1 process. Each user directory is neatly packaged up into a GZIP file and placed where ever the admin indicates in the backup setup.

I use Dovecot so user's email is captured in the backup. ClamAV is set to scan all email that passes through the server so in my mind such a trivial virus should have been caught and blocked before ever being written to the hard drive.

That's just the way I see it. I've been wrong before though. /shrug

 

[nobaloney]

Since no one answered, you could be wrong about those of us using mixed networks. I don't; if others did, and considered your problem a priority, they probably would have responded.

The '-' most likely means the error routine couldn't determine the file name since the syntax of the error should be:

in filename on line 19

Something is returning that to DA and DA is passing it on to you.

Why isn't the username accessible? I don't know. Perhaps a good sysadmin with both Windows and Linux experience could figure it out. You can probably find one hear on the forums.

Where in the GZIPped files were the viruses? In emails? I don't know why ClamAV didn't find them. the ClamAV team is often faster at catching new viruses than the commercial companies, but of course you might want a different checker, or even two (or three).

The admin reseller backup is of course still a relase candidate and ClamAV has never been an official part of DA.

Jeff

Jeff

 

[floyd]

That particular line is less than helpful. 1.) User cannot log in; seems pretty obvious. 2.) Home directory inaccessible; umm... no, the user can get to /home/<username> just fine.

So tell me how the user is able to get to the home directory on the remote server if he cannot login to the remote server? That would be a neat trick.