One server can be the master of several groups. This is how I setup exactly what you’re doing at my old job.

So say you have servers A, B, C, and D, each one geographically separated at their own site. Say that A is the master and has uber amounts of space. Say that B, C, and D have limited space.

Site A’s fog server would be the main server & the master of four groups.

Group 1 - has all images in it and would be the primary group for all images. The master of group 1 is server A, and Server A is the only member of this group.

Group 2 would be for site B. You’d create another ‘storage node’ using FOG’s web interface. You’d use the same IP address, same user & pass, same /images directory. All this would be all the same - but you would name it something like Site B Master. Then you’d configure Site B’s storage node out at the remote location to be a non-master and a member of Group 2. With this setup, only images shared with Group 2 would replicate to site B.

You would repeat this sort of setup for C and for D.

Make sure the main server has plenty of space and compute power. At my old job, with most locations using the same image - and with the shear number of images we had - we burned through 400GB in a flash. I’d suggest you shoot for 1TB or larger - even 2 or 4TB - because you’ll eventually get that one model where no image type works except for RAW and you wind up with a 500GB image file just to support that one dumb model.

Fog was listed as DNS server. We figured out the problem. Someone had entered the address of the Fog machine as a DNS server in IPv4 properties on the workstation. User error, totally unrelated to Fog. Please close or delete this topic. Thanks!

@irishfoguser

not sysprepped

This is possibly the problem. Not everyone syspreps here, but I recommend trying it and see if that alleviates the issue.

@Joe-Schmitt said in SmartInstaller on mac ERROR !:

https://download.mono-project.com/archive/4.3.2/macos-10-universal/MonoFramework-MDK-4.3.2.macos10.xamarin.universal.pkg

Waho… it’s work ! Realy Thank’s !

If you followed this you wouldn’t have the problem: https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG

George is right. Without these things we can’t help much.

@finvader Yes, set your boot order in all the machine’s firmware to Network First, HDD second. By default, if there are no jobs in FOG for said machine, it’s sent to the HDD to boot.

This “sending to hdd to boot” is controlled by the exit type in the FOG Web interface. The default can be set in FOG Settings. The setting can be altered per-host or mass-applied via Groups. The default is SANBOOT and works on most things, for most of the ones SANBOOT doesn’t work on, GRUB usually works. And then there are other options for the really difficult boxes.

I set the boot order in the firmware for 500 systems at my old job. I didn’t do it all at once, I modified the machines one by one as I needed to image them. Over the course of a year and a half, I got them all.

Of course I was also planning on modifying all new machines to boot to the network first as we received them - but then I got a new job.

I’m sorry your post isn’t clear. This is what I think I read.

“We had fog setup in a test environment running on vmware workstation 8”

“We setup a new FOG server with the same settings of the test environment.”

The “we have another server for pxe boot” and “paste into my new fog dhcp server” are confusing.

I have some questions back to you.

I your test fog server (running on vmware workstation) on the same subnet (network) as your new FOG server? On your network where your new fog server is installed, does that network already have a dhcp server installed?

We really need to know about your network to be able to help you.
On the network where new fog server is installed is FOG acting as the dhcp and dns servers?

in the interim, you could always setup rsync until toms worked his magic :-)…

Good news this morning I rebooted the server gave it another try and it all worked.

Tom, Wayne and George, THANK YOU!!!

It’s all good now. And I learned a lot. And archiving this on my end with my notes. Until next time.

I apologize for bugging so much… 😞

@fry_p Your current efforts has not gone to waste. When the other method is proven, you will just move your patched fog.mag.reg to the fog server postinits directory and add in the postinit scripts to copy it over each time. What you have created to day will work just fine moving forward, you just won’t have to unpack and repack the inits after each change.

@darkrelic said in installing now everthing is updated Failed!:

@george1421 that solution works thank you

(Lucky guesser) == George 😉

@george1421

Thanks ill create a checkpoint before i do the upgrade any way but ill give it a go today.

thanks

@Junkhacker Thanks!! I do a lot of monkey-see-monkey-do stuff. So I assume I did what others did to make this work. I applied the chmod -R 777 stuff as well. I checked the NFS services and it’s running.

I can’t say I am troubleshooting because I am applying “fixes” I found through this tread. i know, I know, that’s scary.

I will follow your advice and create a new thread. I suspect some will point me to this thread for resolution but let’s see what happens.

Thank you Tom! Good to know! It is okay for me 🙂

@Wayne-Workman I suspect this problem happens during “reinstall”.

as a root user I can get in but I need to enter root before the command

also from 1.3.0 to 1.3.5

Hi Andreas thanks

Is there a Tutorial somewhere. At least i want to clone into VirtualBox, so i only need a vdi-file from the img-file.

@Tom-Elliott
No, no need an intermediate switch. If I turn-off spanning tree, yes I need to put a intermediate switch, but if it’s on, it’s working.