@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.

I guess I should clarify. We use MDT to create our reference image on a VM with a 40GB disk. During the MDT deploy task we apply all of the windows updates. If we are making a fat image then we install the additional software at that time (using a fat image task sequence in MDT). When we have the image the way we want it, then we sysprep it and capture the image. At this capture point we still only have a 40GB disk. So we deploy that 40GB disk to the target computer and then once on the target computer we extend the disk with diskpart.

We do it this way because we rebuild the golden image each quarter. If you have everything setup to create your reference image automatically, the actual hands on time is very small. What takes the most time from start to finish is windows updates. So far with the WIndows 7 updates it takes overnight to apply them all (~14 hrs).

While I got a bit off point, the key is to deploy a smaller image to your client computers than their smallest disk size then extend their logical disk to the physical size during the cleanup process.

@Drevonovic You are welcome! Do you want to stick with pxelinux or try to get the normal way with default.ipxe up? See my other post and feel free to ask if you need further assistence.

I’ve readded the code that supposedly fixed this earlier. I’m hoping it can be put to bed, but my track record or something.

This issue as well as a few others have been pushed. Thanks for reporting.