@Tom-Elliott Yes, I’m pretty sure that’s the case. I tried copying the SSL files from the main server to the storage node so they would be the same, but that didn’t work. What should I do to fix this? The storage node doesn’t currently have anything the main server doesn’t have so I can start it over if I need to.

@Tom-Elliott I agree, but it was the only thing that made a difference.

@Tom-Elliott I removed the storage node and rebooted the server and it seems to have fixed the loading issue. But I kinda need the storage node.

Additionally, and this is probably related, since updating today the web gui has been having loading troubles.

As seen above, after updating both my main FOG server and the storage node the version information disappeared.

I have tried deleting and readding the storage node to no avail.
I have also tried reinstalling the update on both servers.
Even tried moving the SSL folder back to the default directory on the storage node and reinstalling with the recreate CA and keys options.
Also tried rebooting both servers.

Not sure what if anything I did wrong, it was working fine before the update.

This sounds more like a feature that doesn’t exist than a bug. Just saying
I mean what if you update the kernel in one node but then that kernel has a problem. Wouldn’t you want the stable kernel to stay put on the other nodes?
Or maybe you have a custom kernel on one node but not any others?

Granted it sounds like a useful feature, updating the master node causes all nodes to update, that would be cool. Doesn’t sound all that easy though.

@Sebastian-Roth
Ok let me try to explain at least my idea in a simpler way. I tend to use too many words.

So lets say you have a department like accounting. This department all needs access to the same printers, software, and needs to be in the same OU.
I want to be able to add a host to the accounting group that already has all those settings saved.
So when I add a host to the accounting group I can then apply all the saved printers, OU settings, snapins, and image with a single action.

Does that make sense?

I think @george1421’s desires are a little more complex then mind, but a similar idea.

This logic makes sense.
But doesn’t some of it sort of exist and we just need to add the template part?
I.e. as groups are now you can update an entire group with ad settings, snapins, default image, etc.
But it’s all static and you can’t save what snapins and printers the group always needs. (Currently we just made a doc for each group listing the settings outside of fog)

My point is, maybe you can reuse the existing update group functions with this template idea.

I figure this is relating to this request, just sooner though.
https://forums.fogproject.org/topic/6637/fog-2-0-persistent-group-settings/16

If you need any help with coding or testing this I am happy to be of service.

Isn’t this functionality also available in the GreenFog settings?
I’ve looked at them but never tried playing with them.

@ITSolutions In my experience with trying these kinds of download accelerators it does help on slower connections. While your logic makes sense, since it speeds up a fast connection, why wouldn’t it speed up a slow connection in the same manner?

So just today I had the wonderfully frustrating experience of my internet being slowed down to 1/30th due to an isp problem right when I needed to update fog. Downloading inits, kernels, and the fog client takes a pretty annoyingly long time when you only have a 1 MB/s download speed.
So while I waited for it to finish downloading I looked for some sort of alternative or some sort of configuration that might make it go faster.
I came across a package called axel. Which is basically a multithreaded wget.

http://manpages.ubuntu.com/manpages/precise/man1/axel.1.html
http://www.cyberciti.biz/tips/download-accelerator-for-linux-command-line-tools.html

I found that it installed easily on centos 7 with yum install -y axel and the documentation suggests it’s under the same name in apt-get.
The fog installer had finally finished by the time I found and installed this package, so I didn’t have a chance to test it in the installer. But maybe it’s worth a shot to add it into the install script instead of wget. I mean who doesn’t want to download things 4 times faster?

Updated to ver 6525 before updating the image again.
This time around it worked flawlessly as it should.

@Kazso What kind of troubles.
I have HP 8000 elites on my network and they boot without issue on ipxe.kkpxe (and undionly.kpxe for that matter), I can’t imagine an 8100 is all that different in terms of network

So I came across this the other day and read more into it and found that ipxe.kkpxe may be the way to go. I mostly looked into it due to some older models not working with undionly.kpxe, particularly a HP Pro 3000. I switched my bootfile on the dhcp from undionly.kpxe to ipxe.kkpxe and there have been no issues with any computer booting to ipxe and it may just be me but it does feel a little bit quicker (like a second or two). A few older models have needed different exit types (I’ve had the most success with Grub_first_hdd on older models that don’t like sanboot) But that’s a common problem. So considering that ipxe.kpxe also contains the undionly drivers and that the kkpxe version is more compatible without any downsides that I can see. Why not recommend using ipxe.kkpxe as the default boot file for fog? I’m for it

In summary

Not quite working.
I think a simple change to the “changing permissions” part of the upload adding a chown -R fog.root /images
to the chmod -R 777 /images would do the trick. Or maybe just add that right before updating the database or moving the files.

Well it kept speeding up and ended up finishing about the same time as before, so there was more speed fluctuation than I usually see. So lets just ignore that.

Anyway it is back to hanging at updating database =(
So sadly no, not fixed.

Wait… what.
So while I was editing this post I decided to check the permissions of the images directories.
I noticed they were all set to 777 but owner and group was root.
From /images I ran chown _R fog.root ./ && chmod -R 775 ./ (from an alias if it matters)
Then suddenly I noticed the vm screen started doing things…And boom! it finished successfully.

Perhaps the permissions change in the upload image process needs to also change the owner to the fog user?
That or the updating database part now takes like 10 minutes and it was just coincidence that it worked after changing permissions

Testing now,
First thing I’m noticing is a bit of a speed decrease on the upload. It use to stay around 2 GB/min give or take
This time it dropped from 2 down to 800 MB/min but is speeding back up and settling around 1.4 GB/min. Not a huge deal since my image is only ~23 GB. But it’s just odd that this would change. Might also be the kernel update or something.

I will test you fix as well deleting the current failed to move image first

I just remembered, I recently changed my bootfile to ipxe.kkpxe to test compatibility with some older machines.
Could that have anything to do with it?

I am trying to update my base image as I have done many times (so I’m pretty sure the issue isn’t the image or vm as the last successful upload for this image from this vm was 6 days ago)
I am suddenly getting this message in the apache error log

[Mon Feb 29 14:27:11.998127 2016] [core:notice] [pid 1027] AH00052: child pid 2371 exit signal Segmentation fault (11)
[Mon Feb 29 14:26:50.971240 2016] [core:notice] [pid 1027] AH00052: child pid 4057 exit signal Segmentation fault (11)
[Mon Feb 29 14:26:30.951298 2016] [core:notice] [pid 1027] AH00052: child pid 2368 exit signal Segmentation fault (11)

While the upload is hanging here…

This is the output of top on the server

Running on centos 7 ver 6505 with php 7

Is this just me or are others having this problem?