@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

FOG does support imaging IA32/IA64 compliant Macs. Setting up some of the pxe (netbooting) requirements are sometimes challenging, but that is a Mac thing not a FOG thing.

There is a wiki page that talks about imaging Macs with FOG. https://wiki.fogproject.org/wiki/index.php?title=FOG_on_a_MAC

@Nicolas-Bricet said in One FOG server for multiple teams:

To avoid, for example, accidental deletions of images.

The latest version of Fog records who deletes what images in the history table, in the DB. I had this come up once and asked the senior devs to record who, and they implemented it.

Also in the latest version, there is a checkbox called “Protected” for each image - when this is enabled, fog won’t let the image be overwritten or deleted via the GUI.

Both of those functionalities are only available in 1.3+

You could provide an account to people for the duration of imaging only, then delete their account. You could provide accounts only to your top tier folks, and give everyone else mobile access - so they have to be at the physical boxes in order to image them. Or you could just trust folks, they can do it - you just have to teach them how to do things safely, how stuff works. Let the knowledge flow instead of having a monopoly on it.

I would not recommend a multi-master setup.

I come from a school district at my last job, from a department of about 30 people with the same title, “equals” on paper. We had a 14ish server FOG setup - one master and the rest all storage nodes at all the various schools in the district. Everyone had a fog account. In all training I gave about FOG, I always stressed the responsibility that everyone had to have to use fog - and to be extra careful. Out of 2 years usage and that many people in one big system, there were no significant issues. Just pound it into their heads that they must be responsible - and to ask if they don’t know. Extend an olive branch and show them how things work.

@Junkhacker I suspect the same.

Or, it could possibly be something else. Remember that time I was beating my head against the wall for a week over why the fog server was crippled? Turned out it was a broken fiber cable left laying unfixed for a week by a piece-of-trash contractor that should have been fired.

Not saying it’s a broken fiber cable but… it could be the last thing you would expect, something very wild and off the wall.