@Sebastian-Roth

sry haven`t found this thread before.

Thx for this.

My workaround works only randomly, i think rc.local is the best way.

We had a minor issue with some embedded iPXE script recently. I wonder if this might have caused the hang. Although on most machines it just went straight back to the BIOS without loading default.ipxe… Or it was a corrupted download. Either way thanks for letting us know.

@Wayne-Workman
After reset encyption data works fine.
Thanks for help
Regards

ok so ive changed all the passwords on the server to 1 password and now it is all working
thank you all very much and have a great day 🙂

@george1421 said:

I see the majority of the deployments here are ubuntu.

That’s changing. I strongly push red-hat based distros here because they have been less problematic. I also tend to think that my clearly written instructions for Fedora have swayed the newcomers as well. I’m now working on the CentOS 7 article which is almost a carbon copy of the fedora 21 server article. And then I’ll start on a Fedora 22 server article next lol.

But seriously, just give me a shove in the right direction for partition resizing and I can probably make it really clear and nice looking.

@Sebastian-Roth said:

I am sure you need to spend a lot more days! Take it one step at a time. I don’t know anyone who learned linux and FOG in just a couple of days.

Took me 3 weeks just to get the web interface functional with 1.2.0 on Fedora 21 Workstation… Prior Linux experience, basically zilch. Another 2 weeks to figure out the FTP secomp_sandbox setting needed set… a few more weeks to understand the client and BEGIN to grasp how easy fog can make my job.

This whole FOG ordeal started in February this year (2015) for me. Still learning. And I still occasionally royally screw up too, thank you snapshots and hyper-V!

@Tom-Elliott

That is pretty much what I have with the bashrc settings. The issue is that the no_proxy points to localhost and the script calls the fog server IP address [from my memory].

BUT I could use bits of what you posted with something like this. (understand I already have the exports for the http_proxy… in my bash rc)

no_proxy="<ip_add_fog_server>" ./installfog.sh -y

That would allow the installer script to run unaltered and still tell wget to no proxy for the fog server IP address. I don’t know how big an issue this is or how many fog servers are behind proxy servers. I just wanted to get it documented for others that may find this post.

Also so everyone knows, I helped @sacha-marin earlier. he had two symbolic links pointing at each-other in /var/www and /var/www/html I deleted both of them and that fixed the installation.

@jeremy-mcflight said:

Update: For a strange reason - I have deleted the previous image file, created a new one , re-uploaded the new image, changed back the Deploy method to “PartClone” - and now it’s working fine! However, I still want to thank everyone for giving me a hand. You guys rock!

In that order, exactly? That doesn’t make sense to me.

While I don’t have an answer for you, I do have a feature request out there for the exact same thing. https://forums.fogproject.org/topic/6014/create-the-concept-of-a-foreignmasterstorage-deployment-node
Right now there the only way to do this is manually or scripting via sql dump and sql import of the images and snapins tables between the deployment nodes.

You can do something similar but with storage nodes (not a master deployment node), and you will need to install the /tftpboot files on the storage node. You will need to use the location plugin and storage groups.

Yep upgrade worked like a champ. So in short all it needed on my end was the upgrade and update. But adding the code wouldn’t be a bad idea as most of us wouldn’t think it that far through. Still not sure what happened with NTP.

@Sebastian-Roth
Thanks for reply. I come back to last settings.
Regards

@Tom-Elliott Thank you sir…I’m sorry I didn’t have much info to help diagnose. Appreciate everyone’s help.

Look at the path in the error, ...URL /fog//service... It has two slashes back to back. That’s probably the issue.

What OS are you using? What’s your web-root setting for this storage node set to?

@Joseph-Hales said:

It is likely that I am the only one who is trying to run SVN at this time most large shops won’t upgrade till final release.

And that is greatly appreciated, you’re helping support FOG just by running trunk in your organization and working with the developers on issues. People like you help make FOG releases solid for everyone else.

Per SVN 5211 resource issue corrected…no longer are there excessive apache processes.

This is normal and expected output for OU or any active directory operations from the group I have attempted to make resetting stick for groups so long as every host in the group already have this setting however this is only in the development version 1.2 did not have this feature

Thanks for clarifiying!

Sure you followed this part of Tom’s suggestion: “cd to your fog web directory”?
If not the command might have tried to search through all the files on your whole system. That’s not a real problem bust usually does not come to an end because it hangs when trying to read pipe files (stuff mostly sitting in /var …).

The string is found in those files:

./management/index.php:ob_start('ob_gzhandler'); ./management/static/help.php:ob_start('ob_gzhandler'); ./lib/fog/ProcessLogin.class.php: ob_start('ob_gzhandler'); ./lib/fog/ProcessLogin.class.php: ob_start('ob_gzhandler');

See if you can fix things for you.

Multicast “SHOULD” be the FOG Master Node. Unless your NAS Box can install web and run UDP, it MUST be done with a different box.

That said, NAS’s have a lot of their own problems with FOG Beyond multicast. 1.2.0 just isn’t very friendly with them. I’ve made some strides with the issue’s most NAS’s tend to cause in FOG Trunk, but what you’re wanting to do (Multicast from a NAS) is still not something I would try.

First, as I stated earlier, the NAS would need to be it’s own node completely for it to work best. While many NAS box’s have a form of linux running them, I don’t think they have the utilities available to install UDP-Cast which would be needed.
Your best option would be to mount the NAS’s storage to a more appropriate system that has a FOG Server installed.

Second, if you go with the option to mount the NAS’s storage, the work is, most times, mounted from the network. Multicast just wouldn’t work very well because of how UDP works. UDP spams its packets out without caring who or what see’s them. This, typically, floods a network. As the NAS is network connected, it would also be spammed by these Packets. Essentially, this could cause a complete disconnect of the NAS’s shared filesystem, ultimately affecting the imaging you’re doing.

If you must use a NAS for storage I would highly staying away from Multicast.