@andy.king While the rules I’ve already stated are absolutely true - FOG maintains a great deal of flexibility.

Have a storage group per location, and put one storage node in each group, and make it the master node.

this way, each site can upload to their local master node - as long as the image they are uploading to is assigned to the storage group for that location.

images can also be shared across groups, from master to master - however - this replication is a one-way highway. For example, say we have group A and group B. Each group has one node and it’s the master of it’s respective group. Say you make an image on B and upload. Then say you share that image with group A. The image will replicate to the A group’s master (and then from that master to any other nodes in group A).

But - if you update that image and it uploads to group A, replication will just delete that image and then re-replicate from group B because group B was the original.

These complications and features would only be of use to you if you even wanted to replicate images. If you don’t care about replication, don’t even worry about it. Also - if your WAN link is that slow, maybe you shouldn’t even use replication with fog, maybe you should just sneaker-net the images, or mail them.

While it took longer than I would have liked, OSX auto updating is now finished (you can blame Yosemite for the delay).

So yer right.

Mounting the shared folder is easy enough, but NFS wants a block device with a file system, which a directory is not.

boo.

Back to an attached .vhd I go.

thank you. this post solved my problem

@alorsung said in TFTP/PXE timeout Linux server to Windows PXE boot:

I just pulled the current version, wanted to see what new features, if any, were added.

well, new features aren’t always the goal. Stability, performance, and bug fixes are the primary goal right now. the developers aren’t really adding any more features to fog trunk. from this point out it’s mostly bug fixes and performance improvements, and making fog handle potential issues and scenarios better.

@Connie I’d start off by deleting everything in /images/dev because probably an upload was attempted but not completed due to insufficient space. A lot more work is probably needed though. This is what inevitably happens when you put everything on one partition. There are walk-throughs in the wiki that show how to partition a drive in order to avoid this.

Ah OK, I wasn’t aware of that function. Thank you for your prompt reply. I will give this a try tomorrow!

@pstoric The installer defaults to the (probably) correct choice. Debian would be correct if your installing on Ubuntu. And this choice is not your preference, it’s telling the installer how to interact with the system.

@Souldoubt said in Suggestions for server space recommendation and samba storage:

@Wayne-Workman

Any performance benefits/hits to storing the images in on the same FS as the FOG server?

Nope, other than everything being self contained. That’s how probably 95% of fog sites are. Large sites use multi-node setups.

Is there a best practices document for FOG that I can refer to.

Not really. There are some partitioning considerations that you need to think about, that’s probably the most important thing to get right from the start. Once you get into the groove of FOG, you will start doing things your way. We have some tutorials in the WiKi that are written for the absolute Linux newbie. If you’re a newbie I would recommend following one of the tutorials, and going with CentOS 7 only because it’s tutorial is up to date and I haven’t made tutorials for other distros yet… But if you wanted to go with another distro, we can help you along here in the forums.

@Sebastian-Roth under the Update and Install Packages on https://wiki.fogproject.org/wiki/index.php?title=Ubuntu_14.04 it ask that you run this

cd Desktop/
cd fog_0.32/
cd packages
wget https://svn.code.sf.net/p/freeghost/code/trunk/packages/udpcast-20120424.tar.gz
rm -f udpcast-20071228.tar.gz
sed -i ‘s:udpcastout=“udpcast-20071228”:udpcastout=“udpcast-20120424”:’ …/lib/common/config.sh
sed -i ‘s:udpcastsrc=“…/packages/udpcast-20071228.tar.gz”:udpcastsrc=“…/packages/udpcast-20120424.tar.gz”:’ …/lib/common/config.sh
cd …/bin/
sudo ./installfog.sh

during the “rm -f udpcast-20071228.tar.gz” I hit tab and it did this “rm -f udpcast-udpcast-20120424.tar.gz”.

So I erased the tar.gz that I just downloaded. So it couldn’t find the package which I assume caused the errors.

I hope that clarifies things.

@ghill Can you post screenshots of the area you’re working in to set Option 066 ? The immediate issues are probably there.

But yeah I’d say set up an old computer for testing. And as far as testing iterations go, well… you only need one iteration if you’re following one of our more recent tutorials.

Which brings me back to another point. You said you installed fog based on information in several guides on the internet… Are you aware that the fogproject has it’s own wiki? Things you find on other sites are highly likely to be very obsolete and will probably break more stuff and cause more complications when you try them on FOG Trunk with recent Linux versions.

If you want to make it so you don’t have to comment out port=0 then you can fix this by fixing the resolvconf missing dns server issue.

See this old post for a ton of detail…
https://forums.fogproject.org/topic/2799/dnsmasq-kills-dns-lookup-on-fog-server/6
I know I’ve posted it in a more readable form more recently, but found that one first.

TL:DR
just edit the interface-order at /etc/resolvconf/interface-order to have your main ethernet adapter at the top and be sure to have nameserver lines defined in your static ip definitions if not using dhcp.

Thanks Wayne for taking time to reply.

I will review your suggestions. I’m not really committed to Ubuntu so perhaps changing to OS is worth a look.

@irishfoguser Not sure what we can help you. The solution you mentioned (setup a new RAID and move the images) is perfectly fine!

@Tom-Elliott I know… and was wondering why Wayne posted the “old” URL. Didn’t pay attention and didn’t see that his post is months old…

@Tom-Elliott I updated earlier at work today (like I do most days) and I did notice that “adding needed repositories” took significantly longer than usual.

But - if that’s what it takes to ensure the remi repo gets installed, then that’s what it takes.

Should be fixed in the very latest version!

@mxc Logical partitions were an issue with FOG 1.2.0 when OS type was set to Windows as far as I can remember.

Best to debug things is to start the job/task in debug mode. When creating a capture/deploy task there is a checkbox “Schedule task as a debug task”. Starting the client you’ll get to a linux shell and you can start the task running the command fog from there (description will be displayed as well). Then you can step through the whole process by hitting ENTER. As well taking a picture or video (slow motion!) is always a great way to find out what’s going wrong. When reporting an error we need the exact error message (plus FOG version, server OS, image type and OS type) to be able to understand and reproduce the error.

GPT/MBR is a big chapter. GPT often leaves traces on the disk that might cause an issue. There is a tool called fixparts that you can use from the debug shell as well.

@RipAU Marking this solved as I feel there is nothing much more we can do. Feel free to post again if you have more questions on this.

@xmotion Sounds about right. 🙂