Trouble getting first Image

george1421

For the TZ error, there should be a timezone value in the fog configuration that may need to be set. It should be a nuance warning message but shouldn’t stop the script from running.

The update database and the ftp put error typically indicates that the linux user fog’s password is out of sync with the fog settings.

Did you confirm that the storage node settings are correct and that the password matches what is in the .fogsetting file?

I do have a tutorial on how to resync the fog service account here: https://forums.fogproject.org/topic/11203/resyncing-fog-s-service-account-password
You might want to run through it just in case you missed one of the hiding spots.

lenels2eng

Thanks for the reply @george1421 !!

Yes, I found that article and did run through it. the PW in .fogsettings matches…

I’ve been digging around and found in the PHP-FPM error log (www-error.log) "Failed to open stream: No such file or directory in /var//www/html/fog/lib/fog/fogftp.class.php on line 808

PHP Warning: ftp_put(/images/dev/000c29748171): failed to open stream: No such file or directory in /var/www/html/fog/lib/fog/fogftp.class.php on line 709"

When I look in /images2/dev there is a directory for the image and there are files in it…

not sure why some files transfer and then…it gets stuck maybe???

george1421

@lenels2eng Are you using the location plugin?

Also what are the permissions on the /images/dev directory?
ls -la /images/dev

We had someone else have a very similar issue just last week with the unable to open stream during an image capture.

lenels2eng

@george1421 - I have no idea what the location plugin is or where to even look for it

for permissions I have it set at 777 for all users:

[root@SRV-JMS-FOGTEST /]# ls -la /images/dev
total 0
drwxrwxrwx 3 fog root 46 Nov 30 19:00 .
drwxrwxrwx 4 fog root 61 Nov 30 19:00 ..
-rwxrwxrwx 1 fog root  0 Nov 30 19:00 .mntcheck
drwxrwxrwx 2 fog root 26 Nov 30 19:00 postinitscripts

[root@SRV-JMS-FOGTEST /]# ls -la /images2/dev
total 20
drwxrwxrwx 5 fog  root 4096 Dec  3 20:01 .
drwxrwxrwx 5 fog  root 4096 Nov 30 19:51 ..
drwxrwxrwx 2 root root 4096 Dec  3 20:11 000c29748171
drwxrwxrwx 2 fog  root 4096 Dec  3 19:31 000c29748171.bak
-rwxrwxrwx 1 fog  root    0 Nov 30 19:51 .mntcheck
drwxrwxrwx 2 fog  root 4096 Nov 30 19:50 postinitscripts
[root@SRV-JMS-FOGTEST /]#

[Mod Note] I fixed the post for readability reasons -Geo

george1421

@lenels2eng Ok the issue is with /images2/dev the issue is 000c29748171 is owned by root and not by fog.

It looks like you have 2 drives installed in your fog server. Most likely in this configuration you have two storage nodes defined on your main fog server.

Where that error message is in the capture process about the ftp_put and just before the update database failed The target computer connects back to the fog server and copies the files from /images/dev/<mac_address> to /images/<image_name>. It does this as the management user (fog) in the storage node configuration. This process is failing since what it needs to move is owned by root and not by fog.

I know why is breaking, I’m not sure how to fix it. I have seen posts in the forum where others have had the same issue and resolved it. I also remember something about umask in that it had all files created with 777 mode. That may have been done by NFS, since FOG uses NFS to places the files in the /images/dev/<mac_address> directory.

lenels2eng

@george1421 - I see where the file owner is root instead of fog when the client begins taking the image. I’ve tried resetting it to fog during the process and it does not work; I’ve tried setting permissions on the folder but new files and folders created belong to root; I’ve tried setting ACLs with the same results. I definitely think this is the root cause (no pun intended) but am in training this week so cannot troubleshoot this week. i will try to get back into the server later in the week to see if I can figure out why new folders and files that are created during the process default to root ownership and 0644 permission levels when everything looks like it should be owned by fog and have 0777…

Thanks for seeing this and putting me on the path.

Sebastian Roth

@lenels2eng I am sorry but from my point of view you’re not on the right track yet. Let’s see what information we have:

In the first picture we see ...storage=172.16.30.10:/images2/dev
In your second post you have PHP Warning: ftp_put(/images/dev/000c29748171): failed to open stream
And then we see you seem to have /images/dev and /images2/dev on the very same server.

I think this might be causing the trouble. Why do you have two different directories at all?

About the file ownership: See we transfer the files from the client to the server using NFS. Mounting and file creation is done via root user as we don’t have the same fog user account (and more important same UID) on the client. Access rights might only be changed at the end when the imaging finishes properly and FOG is able to move the newly uploaded image from /images/dev/<mac_address> to /images/<image_name>.

lenels2eng

@Sebastian-Roth - thanks for the reply!!!

I actually added a drive to my fog server and chose to give it it’s own location and storage node. Should I not? This is a VM and I used a 16 GB vdisk for my OS so I didn’t give it any space for images. After my OS was solid, then I added the 2nd vdisk…

should I just start over with a larger vdisk???

So in the file ownership side, I think I get it. The files are made under root in the MAC directory, then moved/copied to the imagename directory because there is no fog user on the client side to authenticate with.

Thanks again for the assistance!!

Sebastian Roth

@lenels2eng said in Trouble getting first Image:

should I just start over with a larger vdisk???

No need to I reckon. You can simply merge those together. See if you still have any images left in the original directory ls -al /images. If so, move them to the other one mv /images/<image_name> /images2/. All done, then clean the old directory - not actually needed, but might prevent from further confusion rm -rf /images/.mntcheck /images/dev /images/postdownloadscripts (think before you do this). No unmount the 2nd vdisk umount /images2 and remount mount /dev/sdXY /images. Make sure you have the entry also in your /etc/fstab file correct for next reboot. Then remove the second storage node definition and simply go with the single one in /images…

Be careful with this, it’s just written down and untested. Your situation might be a bit different to what I expect. Please double check and don’t run the commands blindly!!

lenels2eng

Sorry about the long intervals between posts. Just finishing up internal product training…

SO… I did as @Sebastian-Roth suggested and was able to successfully take an image and push it down on a blank VM! I have not tried putting the image back on the source VM but thought I would report back that I am successful and appear to be all set.

The take away from this is having 2 storage nodes on the same machine is not a great idea. If you run out of space, add a HDD and mount it /Images to add space.

Thank you @Sebastian-Roth and @george1421 for your help and guidance!

Trouble getting first Image

188

11.6k

17.1k

154.6k