SOLVED Trouble getting first Image
Thank you in advance for your efforts in helping get FOG up and going…New install on Centos 7.5.1804 (Core) and FOG 1.5.5. I have the FOG server running and all looks good from the web interface. I am able to get a PXE client to boot and get it to register and inventory a new client. When I go to take an image of that client it gets most of the way then can’t complete. “error returned: Type: 2 File: /var/www/html/fog/lib/fog/fogftp.class.php, line 709, messageL ftp_put():” Then some stuff about UTC time zone.
So I verified I can FTP into the box as the FOG user, set permissions on the TFTPBOOT directory and the /image/* directories, made sure the password matched in the web interface in FOG settings, in the storage node settings, and generally everywhere I could find it.
I made sure the timezone in the OS matches the web interface, set to UTC on both sides.
The imaging begins and does fine until it goes to text screen and I get a bunch of errors (above) then the “An Error has been detected!” and the kernel variables…
I’ve searched through and can’t find an answer…
Any help would be greatly appreciated…
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.
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 /images2and remount
mount /dev/sdXY /images. Make sure you have the entry also in your
/etc/fstabfile correct for next reboot. Then remove the second storage node definition and simply go with the single one in
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!!
@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!!
@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
- 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
/images2/devon 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
foguser 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>.
- In the first picture we see
@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.
@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.
@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
@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.
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???
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.