/opt/fog/snapins disappearing

[apathetic_admin]

This just happened to us last night. We’re on 6152.

[Tom Elliott]

@apathetic_admin so the files are only deleting when a new file is uploaded?

[apathetic_admin]

@Tom-Elliott I’m not sure. I’m about to copy them back over and then upload a new file through the snapin manager. Will report back.

[apathetic_admin]

@Tom-Elliott

I copied my snapin files back over from my old server, and I opened an existing snapin and uploaded a new version and the other snapins files are still there.

I created a new snapin, uploaded a new file, and the other files are still there.

I created a new snapin and selected an existing file and it wiped out all my snapin files.

My guys are saying

“Because after I uploaded the new Chrome, the list of files disappeared and only the one I uploaded was there.
As in, where it says “Snapin File (Exists)” where I can select already uploaded files. It had all the other files listed, then when I made the new spapin and uploaded Chrome, they all vanished, except the new chrome.”

[Wayne Workman]

@ITSolutions said:

If I try to create a snapin without a file associated with it it deletes all the snapin files in my /opt/fog/snapin directory.

Just from programming experience and from how the issue is described by ITSolutions,
Most likely, what’s happening is

Before the web interface uploads the snapin, it deletes any of the same name.

so for my.msi it’d delete /opt/fog/snapins/my.msi
if the file field is blank
it’s probably doing this:
delete /opt/fog/snapins/

Just a guess.

[ITSolutions]

@Wayne-Workman That makes perfect sense, I hadn’t considered that it might need to delete an existing file before uploading a new file. I think a check in the code to ensure a file is selected before going further would solve this. I am not a PHP or HTML coder at all so unfortunately I wouldn’t be able to help much with this. I can script in windows and a little it Linux but not sure that will do much in this case.

[Wayne Workman]

@Wayne-Workman I think I found the problem and I’ve made a fix here: https://github.com/FOGProject/fogproject/pull/82/files

Specifically this file: /var/www/html/fog/lib/pages/snapinmanagementpage.class.php at line 161

You can try it out, but Tom will need to review it and merge for it to be put into the main fog repo.

[apathetic_admin]

@Wayne-Workman
I made the same change as what you made and now I am getting

FOGFTP: Failed to put file. Remote Path: /opt/fog/snapins/, Local Path: , Error: ftp_put(): Filename cannot be empty

[Wayne Workman]

@apathetic_admin Are you uploading a file or not?

[apathetic_admin]

@Wayne-Workman No, just selecting an existing file. This is what caused it to delete all the snapin files before.

[Wayne Workman]

@apathetic_admin Small change, try this: https://github.com/FOGProject/fogproject/pull/82/files

You’re just basically moving the closing } down below the put statement, that way the put never happens either if the filename is blank.

[apathetic_admin]

@Wayne-Workman That seems to have done the trick.

If I select a file to upload, and I select a file that’s already existing, I get the new file uploaded when I update the snapin, but the snapin is configured to use the existing file I selected in the dropdown. That might not be related at all to anything we just did, I just tried it out to see what it’d do.

[Wayne Workman]

@apathetic_admin Awesome. Now, can someone please take a deep breath and try to create a new snapin without a file ?

[apathetic_admin]

@Wayne-Workman I was able to add a new snapin without doing anything but putting a name in and selecting the storage node. I suppose that’s okay though, yeah?

[Wayne Workman]

@apathetic_admin said:

@Wayne-Workman I was able to add a new snapin without doing anything but putting a name in and selecting the storage node. I suppose that’s okay though, yeah?

The real question is were existing snapin files deleted again?

[Tom Elliott]

@Wayne-Workman I’ve added your code and then I made a bunch of modifications to more appropriately check things.

First, uploaded files – I think – should always supersede the “existing file” chosen. So this is now implemented.

My checks do now verify if the file exists before attempting to delete it. However, most notably, I think, the code will not attempt to even create/edit the source if the snapinfile choices don’t exist (aren’t set). It will ONLY delete the file in the case of the uploaded file, and even then only if the file exists first.

Hopefully this fixes the issues described here and in the other thread.

[RipAU]

@Tom-Elliott I Just updated my storage node with the latest SVN to fix the Snapin issue and noticed an error at the end.
It did report that it installed everything correctly and seems to be working but the errors I noticed are

 * Starting FOGScheduler.service Service.......................OK
 * Starting FOGPingHosts.service Service.......................OK
 * Setting up exports file.....................................OK
 * Setting up and starting RPCBind.............................OK
 * Setting up and starting NFS Server..........................OK
sed: -e expression #1, char 76: unknown option to `s'
sed: -e expression #1, char 88: unknown option to `s'

 * Setup complete


 * You still need to setup this node in the fog management
 | portal. You will need the username and password listed
 | below.

 * Management Server URL:

I thought I would reply here as I thought this might be related to the latest fixes?

Cheers!

[apathetic_admin]

@Wayne-Workman Yeah sorry I thought I had mentioned that earlier. They were fine.

[Tom Elliott]

@apathetic_admin This errors should no longer be present and the random deletions are fixed. I’m going to solve the thread.

[ITSolutions]

Sorry for not responding earlier, Yes this is solved. Thanks again for all the hard work @Developers and everyone else.