FOG won't move images

[Quazz]

Hi, I’ve been over the FTP troubleshooting guide, followed each step and confirmed that FTP is indeed working, correct passwords everywhere (I can copy paste the password from any location into the ftp client and it works), but images are unable to be moved.

The FTP config file is identical to the one on the wiki as well. Ownership and permissions should all be fine. (0777, fog:root)

As for the log files, I can’t see any of the FOG Service log files anymore.

[george1421]

What version of the trunk are you on?
How do you know ftp is not working? (i.e. what problems are you experiencing)
Does any of the log files in /opt/fog/logs show any clues to the problem?

[Quazz]

What version of the trunk are you on?

Latest trunk version.

I just noticed though that it seems to change the fog user password every time I update it (even though the password in /opt/fog/.fogsettings is 100% correct, I copy pasted it from TFTP Server settings before updating)

How do you know ftp is not working? (i.e. what problems are you experiencing)

FOG moves the images using FTP from /images/dev to /images, which it fails to do for me.

Does any of the log files in /opt/fog/logs show any clues to the problem?

There’s only groupmanager.log and servicemaster.log in there

Servicemaster reports all FOG Services running.

Nothing relevant in groupmanager.log

[Tom Elliott]

@Quazz Is this same password set properly on the storage nodes? FOG Uses the storage nodes username/password settings for FTP during upload/replication. If, for whatever reason, these are incorrect, it will not work properly. That said, can you check what settings are actually stored in the DB?

I do a lot of escaping of characters in an attempt to prevent XSS issues and SQL Exploit issues. Because of this, special characters might (I’m fairly sure this isn’t the case, but I’ve been wrong many a time before) be stored and used incorrectly when actually needed by the system. For example, TheP@sswordHere%hasSpecialChars/ would be translated in the system (but should be decoded properly) as TheP%40sswordHere%25hasSpecialChars%2F.

Again, this is all speculation, but it’s the best guess I can think of at the moment.

[Quazz]

@Tom-Elliott Yes, I’ve force set the password everywhere.

What table should I check in the database for the password? There is a = in the (auto-generated) password so that could possible cause issues then.

[Tom Elliott]

@Quazz The table, I think, is nfsGroupMembers

[Quazz]

@Tom-Elliott The password is correct in the database.

[Tom Elliott]

@Quazz Is there anything in the vsftpd logs?

[Quazz]

@Tom-Elliott There is no vsftpd logfile! Most strange, since it’s definitely enabled in /etc/vsftp.conf

However, there is this when I check the status of the service: (I’ve been trying to upload images the past few hours)

apr 11 10:51:38 foghost systemd[1]: Started vsftpd FTP server.
apr 11 10:59:04 foghost vsftpd[10206]: pam_unix(vsftpd:auth): authentication failure; logname= uid=0 euid=0 tty=ftp ruser=fog rhost=192.168.1.154  user=fog
apr 11 11:55:12 foghost vsftpd[11194]: pam_unix(vsftpd:auth): check pass; user unknown
apr 11 11:55:12 foghost vsftpd[11194]: pam_unix(vsftpd:auth): authentication failure; logname= uid=0 euid=0 tty=ftp ruser=anonymous rhost=192.168.1.31
apr 11 11:55:32 foghost vsftpd[11196]: pam_unix(vsftpd:auth): authentication failure; logname= uid=0 euid=0 tty=ftp ruser=fog rhost=192.168.1.31  user=fog
apr 11 11:55:40 foghost vsftpd[11199]: pam_unix(vsftpd:auth): authentication failure; logname= uid=0 euid=0 tty=ftp ruser=fog rhost=192.168.1.31  user=fog
apr 11 11:56:23 foghost vsftpd[11212]: pam_unix(vsftpd:auth): check pass; user unknown
apr 11 11:56:23 foghost vsftpd[11212]: pam_unix(vsftpd:auth): authentication failure; logname= uid=0 euid=0 tty=ftp ruser=anonymous rhost=192.168.1.31
apr 11 11:56:26 foghost vsftpd[11214]: pam_unix(vsftpd:auth): authentication failure; logname= uid=0 euid=0 tty=ftp ruser=fog rhost=192.168.1.31  user=fog

So clearly it passes along the wrong password for some reason, but I can’t figure out why.

[Tom Elliott]

@Quazz Hit me on chat, we should do a “join.me” session I think.

[Quazz]

@Tom-Elliott The log thing is definitely fixed, but it seems it still doesn’t move images. I noticed that it by default assigns root:root as ownership of the folders in /images/dev, could this be the problem?

[Tom Elliott]

@Quazz What’s the modifiable permissions?

root:root shouldn’t matter much, but in the move process, itself, it should be set to fog:fog or fog:root. How’s it maintained in dev? Here you want to just output the listed output of the directory.

Try:

chmod -R 777 /images

It should correct the issues for you, though test would be needed to validate.

[Quazz]

@Tom-Elliott

root@foghost:/var/log/fog# ls -la /images/dev
totaal 16
drwxrwxrwx  4 fog  root 4096 apr 11 14:47 .
drwxrwxrwx 24 fog  root 4096 mrt 15 15:00 ..
drwxrwxrwx  2 root root 4096 apr 11 14:46 08002710d395
drwxrwxrwx  2 root root 4096 apr 11 14:48 0800276fc5ee
-rwxrwxrwx  1 fog  root    0 mrt  2 17:05 .mntcheck

So, I guess it’s not a permission issue then. Same permissions for /images

Also I found the vsftpd log, it was named xferlog (after some googling this is merely a transfer log?)

Mon Apr 11 14:46:45 2016 1 192.168.1.154 0 /images/W7PRO64FR b _ i r fog ftp 0 * i
Mon Apr 11 15:07:29 2016 1 192.168.1.154 0 /images/W7HPR64NL b _ i r fog ftp 0 * i

This is the log of the images of just now.

[Wayne Workman]

@Quazz what OS do you use? Have you checked selinux, firewall?

[Quazz]

@Wayne-Workman Ubuntu, and yes all disabled. Don’t worry though, Tom nearly has it all sorted, should be ok tomorrow.

[Sebastian Roth]

@Quazz If you still cannot make it work show us the output of mount here in the forums. Possibly the filesystem is ext3?

[Quazz]

@Sebastian-Roth

/dev/mapper/ubuntu--vg-root on / type ext4 (rw,relatime,errors=remount-ro,data=ordered)

I haven’t had the time to test it properly since yesterday, Tom was pretty busy yesterday as well, but from a quick test it did seem to be able to move the images (if the target directory didn’t already exist)

[Sebastian Roth]

@Quazz said:

but from a quick test it did seem to be able to move the images (if the target directory didn’t already exist)

This sounds exactly like the issue I had some time ago with images being stored on a ext3 partition (see below). Possibly you are not running into the same but a similar issue - FTP timing out because deleting the old (huge?) image takes some time. Maybe play with FOG Setting FOG_FTP_TIMEOUT…

@Sebastian-Roth said in Failed to create deployment tasking…:

Learned something new … (pretty much every day!)
ext3 does some kind of defragmentation/reallocation foooo when files are being deleted!
http://www.depesz.com/2010/04/04/how-to-remove-backups/
I (re)moved all my images, re-formated with ext4, put it all back together and now everything seems fine. Deleting of 150GB image takes less than 10 seconds. Awesome!!! I really wonder why very little people have issues with this. Is ext3 not in use in most recent distributions??

[Quazz]

@Sebastian-Roth Well, it’s definitely in ext4, so I’ll try to up the FTP timeout and see if that helps.

[Wayne Workman]

@Quazz Does /home/fog exist ?