@george1421 said in When Does FoG push the Image VIA FTP to Location Node:

Replication should start soon as the imaging task is complete and the image is marked OK for replication. Replication will start.

The image replicator has a sleep setting here:
Web Interface -> FOG Configuration -> FOG Settings -> FOG Linux Service Sleep Times -> IMAGEREPSLEEPTIME

The default sleep time is 600 seconds, which is 10 minutes.

So the image replicator by default will begin replicating the image after capture completes anywhere from 0 to 10 minutes later.

I would not recommend the secondary server being a full server - this setup isn’t supported and things can get hairy - and there’s manual work involved - nowhere in the wiki is it documented - and I wouldn’t recommend it. Especially with the awesome new features for access control coming probably next release.

For more information about replication, see these two articles:
https://wiki.fogproject.org/wiki/index.php?title=Replication
https://wiki.fogproject.org/wiki/index.php?title=Location_Plugin

@adukes40 I don’t know how you guys do it where you are but… I’ll elaborate on my experiences with imaging 2k boxes in a summer for over a dozen locations…

The shipment of systems came in all to one building. We inventoried all of the systems at this building & then reboxed them - and created separated stacks for which ones go to what building.

The stacks were then transported to their pre-determined building. Once there, they were unboxed fully - and smaller stacks were made for what rooms they went into.

These stacks of computers were registered with “Full Host Registration” and given their correct name (part of the name included the building, the room they were in, part of the asset tag, the type of system it was, etc) and imaged.

Once the imaging process was started; keyboard mouse & monitor were removed and plugged into the next. We monitored progress in the fog web interface, in Task Management & intervened if there were problems. Systems fully imaged, joined to the domain 100%. When all was done, we’d connect monitor, keyboard, and mouse to shutdown the system (because we set the power button to do nothing because kids are brats).

It was quite graceful a process. Systems queued up and waited for imaging - one centralized fog server was orchestrating everything from a central location - all locations were using their local storage nodes & we were using the location plugin.

@Wayne-Workman The export will not be un-encrypted, for now, but the import CAN take unencrypted form.

@Avaryan That works.

It’s probably possible, but that doesn’t mean it’s a good idea. I wouldn’t recommend it.

@lebrun78 OK I just had a chat with the developers over this.

zstd is used for decompression of both legacy and new images (as of FOG 1.3.5). You have the option of using industry standard gzip for image compression or the new zstd for image compression. If the industry standard gzip compression is used, you “could use” any zip program to extract the image from the FOG archive (not very common and only done for a very specific reason).

The newer zstd format can achieve better data throughput (target hard drive compression and decompression) than by using the gzip format. They (the developers) switched to zstd based on a feature request to make FOG imaging even faster (the FOG Project is all about going faster) and with a tighter packed image on the FOG server (smaller disk space used on the FOG server’s hard drive).

The real decision not really a decision. Use zstd and live with the faster deployment speeds, or use gzip and deploy as the same zippy speeds the previous versions of FOG 1.3.x supported.

Really its not a decision use zstd and worry about other things in the world.

Any news on this. Would love to buy a shirt or 10

@bacprotr49 Excellent. Is it OK to close this ticket?

FOG Doesn’t keep track of “group” history in an individualized manner. We do keep a history of “everything” in the ‘history’ table of the FOG Database, but it’s not intended to be used as a “reporter” rather right now it’s used more or less as a means to troubleshoot and track unexpected items as they may occur. It does log add/remove/create history but it ties in with “everything” not just groups, or hosts, or images.

We don’t keep track, at an individual item level, that far down. We have such fields as:
‘Created Date’ and for images and hosts we have the ‘last capture and depoy’ times stored individually.

@x23piracy When you run the installer, use the:

-S --force-https Force HTTPS redirect arugments with the installer.

So if you want https support, you would run your installer as:

./installfog.sh -yS

Maybe FOG_PIGZ_COMP can be changed to just FOG_COMP or IMG_COMP
At the end of the day though, it doesn’t really matter.

@dloudon96 Just go ahead and stick the extra drive into the box - hook it up however you can, leave the old drive in there and don’t change it’s cables around. SATA II and up is hot-swapable so if you’re just working with SATA III you don’t even have to power the server down to add the disk but you can if you want. After that, run the below commands and provide us with the output (in a nice code-box please). We can get more specific with what’s next after this.

lsblk pvdisplay vgdisplay lvdisplay df -h fdisk -l

I’ve wanted to give FOG classes for years. But it’d take more than just you signing up for them (paying in advance too, I shall not be blown off).

Oh, nice. Sorry didn’t see that. I just started watching the video, as I plan on moving to PDQ within the coming year.

Glad they did this.

Update, I created the .fogsettings file and updated. It would not let me update the schema so I added the MySQL credentials (instead of leaving them blank) and update was successful. Things, host, users, images, etc, look good from the FOG webpage. I will do some testing next week. This is a XEN guest so I have copies. We have not imaged yet, (purpose of upgrade was for XP and Vista imaging). DBAN errors out with a chaining error, we use HTTP to load DBAN. I will do some testing next week.

Thank you for your help. In our environment starting from scratch is easy but then we would not be as familiar with our install.

@ITCC I’d make sure on both fronts.

Yes, tick the box in the fog settings, but the “checkbox” is typically checked on hosts even if they’re not “enforcing”. This because it get’s its information from the FOG Settings -> Active Directory Defaults -> Similar named checkbox setting.

Just because this is checked on the host does not mean it’s actually set. It’s not because I like making people confused, but rather how the checkbox is checked. I can’t know which method you’re intending for while being able to auto-set the box when you do want to enable domain join and what not, so this is set based on the value in the default location specified above.

@Tom-Elliott that’s what i meant to convey. the default is 10, and that works fine for most in initial setups and test environments. it’s up to the person running the server to monitor and adjust settings to fit their environments optimal configuration.

@george1421 It worked!
I clicked on the host name in the list and in that page reset the encryption data. Now that host has joined the domain and got the right printer.

I will now do these steps on our master image.

Thank you for your kind and patient help.

alt text