https://www.reddit.com/r/sysadmin/comments/a727a8/fog_appreciation_post/

@Jbob said:

Tom is just … Tom.

that’s like saying: Superman is just … Superman.

trunk 7609? is there a reason you upgraded to a release that’s almost 2 months old? i think this has been fixed already.

@wanderson fog 0.32 was released in 2011. i’m afraid none of us know how to support it. it may be time to upgrade or migrate to a new install of fog. there have been far more than enough improvements to be worth it. your existing images will be compatible with the latest version of fog (as legacy images. if you migrate to a new server instead of upgrading a few setting will need to be set to recognize them properly, but they will work)

don’t forget to get the proper licensing. you can’t capture an OEM image and redeploy it to other computers and be in compliance with Microsoft’s licensing. you’ll need a volume license.
once you have an imaging server, you’ll find yourself using it a lot more than you think. user has a virus? a few hours to repair, or a few minutes to reimage, etc.

@VincentJ default compression level is 6. testing found that it had the best compression/performance ratio for us. i don’t think many people change it.

@Junkhacker to clarify, your new “default” menu item would contain something like this:

iseq ${serial} <labSerial1> &&  goto chainboot ||
iseq ${serial} <labSerial2> &&  goto chainboot ||
goto fog.local

:chainboot
set net0/next-server <otherPXEbootServerIP> && set filename <whateverFile> && chain 
tftp://<otherPXEbootServerIP>/<whateverFile> ||
exit

@dwagner sounds like you need to recreate the /images/dev/postinitscripts directory, and it’s contents, a single file named “fog.postinit” with the contents

#!/bin/bash
## This file serves as a starting point to call your custom pre-imaging/post init loading scripts.
## <SCRIPTNAME> should be changed to the script you're planning to use.
## Syntax of post init scripts are
#. ${postinitpath}<SCRIPTNAME>

permissions 777
also, you’ll need to create an empty file named “.mntcheck” in /images/dev too, if you haven’t

@george1421 this one? https://forums.fogproject.org/topic/9396/stopping-web-service-failed/8?page=1

ok, here are my pseudo scientific results:

pigz vs pzstd (parallel implementation of zstandard, experimental)
tests were performed using a windows 7 image
(larger of 2 partitions only)
uncompressed image file size:34650439624

(de)compression tests were performed as closely as i could to emulate fog’s operation methods (without doing too much work :P). files were cat-ed from a mounted nfs share and piped into the programs, with results saved to an SSD. test machine was running Lubuntu instead of a custom FOS init, because i’m lazy.

pigz -6 compression
duration: 6:06
file size: 17548659028

pigz -6 decompression
duration: 6:00

pzstd default (3?) compression
duration: 5:16
file size: 16967988207

pzstd decompression default compression file
duration: 3:17

pzstd -6 compression
duration: 6:11
file size: 16247155611

pzstd decompression -6 compression file
duration: 3:16

pzstd -9 compression
duration: 10:00
file size: 16084180231

pzstd decompression -9 compression file
duration: 3:21

Edited to add zst compression level 6

@richard-wise if you go the route of using an external csv file, might i suggest putting it in the /images/postdownloadscripts directory of the fog server? it’s a location that will be mounted anyway

@g-sivakolunthu while possible, it’s not what fog is made for and you would have a bunch of manual steps. you might want to look at clonezilla for imaging with online images possibly in combination with gparted for partition resizing.

@florent in my alternate setup, only the machine you use to upload images to fog would need NFS enabled. the hosts you deploy to would not.

@george1421 i have had in the past fog working without NFS completely (for downloads. uploading images to fog still required NFS, but that’s easier to lock down since you can limit access by IP or whatever for your image source machine)

if there’s any interest, i have ideas on how to re-implement fogtorrent (fog imaging using bit-torrent) though my time to participate in it’s developent (and skill level) are limited/

@brakcounty i don’t know what’s going on, but make sure you don’t have any typos and that you’re running the script with python3

@brakcounty from a bit of googling, it looks like maybe something changed in the module. where i have “username” you should replace with “user”

@florent securing fog has always been one of the biggest challenges. there isn’t a good way to secure postdownloadscripts while still allowing them to be accessible by FOSS. what could be done if you have anything requiring some level of security would be for the script to not actually be what you need done, but a reference to an external source for what you need. a https address for example. the files you’re serving up from that source could be secured and access restricted based on what the FOSS knows or the FOG server knows (i.e. host with this ID in the system and an active imaging task is allowed download access)

@brakcounty this is definitely a VirtualBox issue, not a fog issue, but as i recall VirtualBox uses a version of iPXE as it’s built in network boot rom. maybe you can directly swap the binary with an updated one?

@brakcounty find the password in the config file fog uses to connect to the database.

make sure the directory you told it to use is correct. compare it to the other working images. and remember, it is case sensitive. are there any unusual characters in the path? did you put in the full path instead of the folder name by mistake? does the image show up on the list of images when you browse there? (perhaps you forgot to save)

@brakcounty use pip to install the mysql connector module for python