Posts made by JGallo

@tom-elliott I’m going to upgrade right now. I can try it and check back.

I would also add that maybe resort to an older version that is more stable without the features you may not even utilize. Stick with that version and you will be fine. If you want to tinker on the latest, throw another box online and test it. That way you don’t impact your production environment until enough bugs are patched on latest releases. I think too many people jump on the latest version of FOG and expect it to be perfect. As with any software release, bugs are expected and given the great community of FOG with feedback, it will get patched.

@fog_rob Were you able to resolve this issue? I didn’t see any responses so I’m almost tempted to just reinstall from scratch. Even with update to 1.5.3 the issue persists for me.

I noticed after tinkering with the web UI images settings that if you configure the image and uncheck replication then also set the storage group to any other one than default it will not rename the storage groups for other images provided you do not try to remove default from within that storage group. What I’m not sure of is if you have multiple storage nodes in a storage group if that replication setting will not allow the image to replicate to those storage nodes in that particular storage group now if it’s unchecked.

@vince-villarreal I understand. I really think our issues are related. I say this because I initially experienced the same thing but updating fog and nodes worked for me for now. We haven’t had the need to image from other locations so i’m not 100% sure it’s actually fixed. I experience same issue only when uploading image and for some reason it was going to separate subnet lol. That’s resolved but not sure about actual imaging. We are getting ready to image for summer projects so I’m going to have some techs image from other locations on separate subnets to see if I’m having the same issue.

I just noticed also that when you uncheck the replicate option on the image, update, then make your changes in the image storage group it will not change the rest of the images location storage group. Then if you have multiple storage nodes in that storage group you could re-enable it in the image options to replicate and update. No issues to rest of images. Weird observation though.

@tom-elliott reading through that post, and just having to create a new image on my fog server version 1.5.2.28 it does exactly what the post states. When I try to change the Storage Group from default to the Storage Group I want it will change all the images location to default except the one I just changed.

I had similar problem except that instead of deploying I was trying to upload image but it was going to different Node on seperate subnet. I updated the master FOG server and it resolved itself. I was on 1.5.2 but then after switching over to working branch and updating to 1.5.2.28 it worked out. Really weird though.

Glad that helped. The beauty of an active forum where ones struggle becomes others solution. Pretty cool.

@george1421 said in Replication issue:

The master node in each storage group must be a full fog server (this one I’m 80% sure of).

Question about this condition, how would you handle the databases of each full fog server if each master node is a full fog server? I’m sure there is some tricks that have to occur but there has to be an easier way. The way I have my storage nodes is I have 18 sites and one full fog server. I have set various nodes as a master to their respective storage groups and have storage nodes within those storage groups that are not masters. Images will replicate within the storage groups as defined in the image settings with only one full fog server and its database. With the location plugin, I use the inits and kernels from the storage nodes that are masters to that particular storage group. I think it works great to be honest. The only dependency is when registering a client, you would have to make sure the image for that particular machine exists in the storage group for that location.

Would having full fog servers for the masters nodes be easier? At least in the sense that ipxe doesn’t occur across the WAN?

That happened at first to me as well and then the next day it turned to some very large numbers like mine.

Hello, so I updated to 1.5.2 and notice various changes. Very nice and I did notice it’s a lot snappier. Weird thing is the bandwidth graph is very awkward. Not sure if this is by design or a bug. Here is a screen shot of what I’m talking about:

Notice on the left the rates. Also, storage node FOG versions are no longer showing. Just Node() with empty brackets. I must also say that I ran updates on Ubuntu Core 16.04.4 LTS and had php7 updates but I did not update and kept older version instead. Could that be it causing the FOG web UI issues? Thank you.

@daniel-dillard

Thank you. That is weird. Probably something on githubs end. Hopefully @george1421 or @Tom-Elliott could help.

Do you have a proxy server set on your system trying to access the web ui? If so, try disabling the proxy to test. I had that issue and it worked. Hopefully it can help you.

May I suggest the following:

https://forums.fogproject.org/topic/9851/custom-full-host-registration-menu-for-1-4-0-rc2-and-later

You may edit the registration process by eliminating questions you don’t want to deal with. Hence cutting the registration process depending on how many questions you eliminate. What I have done is removed unnecessary questions like product key, group, etc so that only three important questions are asked. Name of host, image ID, location, and then image now. If you have groups, you could just use the web ui to group them together. Mind you, this is only a suggestion to your scenario as my environment has several storage nodes and master nodes within those storage nodes and I replicate images across domains. Pretty cool in the end that FOG is capable of this.

@bardwood

Is it possible that the replication hasn’t finished prior to the next image replication check occurs? That happened to me and I had to increase the IMAGEREPSLEEPTIME for storage nodes on networks with slow connections.

@dpotesta50

OK. So if the image you have defined on the Web UI is named New_Windows_Test10-9 then the location of that image is /images/New_Windows_Test10-9 but remember that it will not exist if it’s a new image because your FTP credentials are not working right now. So there is no way for it to exist unless you create the folder manually. Hence why it would be imperative you focus on figuring that out as well so you don’t need to do this tedious work around. In any case as long as the directory is matching what you defined in the Web UI when creating a new image then you can simply use the mv command into that new location.

@dpotesta50

Place the newly re-named file from /images/dev/(name of image) to /images so it resides outside of the dev folder.

@dpotesta50

Yes. You would need to connect to the FOG server via FTP from your computer. I would highly discourage from using this method because if you have storage nodes replication gets out of wack at least in my experience. I believe something to do with file permissions to the directory.

If you are just worried about getting the image over to the proper directory and get working that it easy but doesn’t resolve the bigger problem. You could just re-name that folder with the MAC address with the name of the image you defined in FOG and place it in the /images folder. As long as the name matches and all the files from the screenshot you took are placed in there, you should be fine to deploy the image. Hope that makes sense.

@dpotesta50

It’s not the wrong folder. As @george1421 states that folder where the files of the image you uploaded are is a temp folder so to speak so that once it’s completed uploading then the next task is to move it to the images directory. That is what FOG does. So it’s clear at this point that it’s definitely a credentials issue here because the image does upload but the very last step for FOG is to move those files to the Images directory but it can’t because it requires the proper credentials.

I would re-read the suggestion @george1421 said earlier and examine your files to confirm credentials are accurate. I hope that helps.