@george1421

I have modified the storage group in my image definition.
I have:

cp -R /images/Dellvostro430 /images2/ sudo chmod 777 -R /images2/Dellvostro430 sudo chown fog.root -R /images2/Dellvostro430/ rm /images/Dellvostro430

I have updated the configuration for my client with the image definition modified.

And the result :

0_1500383292579_vostro430.jpg

I think it works but i waiting the end of deploy

Edit:

It works 😄

After cp + rm
Node 1:
0_1500383895890_1.jpg

Node2:
0_1500383908488_2.jpg

The final result:
0_1500383925687_3.jpg

For information, i don’t have used mysql. I can not use it anymore

Thank you one more again @george1421

@george1421 said in Can you make FOG imaging go fast?:

I can say from my production FOG server running 2 vCPUs on a 24 core vSphere server, I can achieve about 6.2GB/min transfer rates (yes I know this number is a bit misleading since it also include decompression times, but its a relative number that we all can see) for a single unicast image.

That figure is not network transfer speed or compression/decompression speed nor is it an aggrigate, it is simply write speed to the host’s disk.

It doesn’t represent or reflect network transfer speed or decompression speeds. These things are very loosely related to the write speed just as the disk you’re using is related to the write speed - but this figure does not tell where any bottleneck is.

Trying to use this figure to gauge network transfer speed would be like trying to gauge the mail man’s speed based on how long it takes me to go check my mailbox (if the post office used that as their metric, the mailman would be fired because I check my mail every few days).

Further, your bottleneck is probably not the next person’s bottleneck. My experience with multiple FOG servers on multiple types of hardware has shown that tuning FOG is a matter of balancing network throughput with a host’s ability to decompress. We cannot speed up how fast a host’s disk can write, it’s maximum write speed is still it’s maximum write speed no matter what we do with CPU or Network or Compression or RAM - the idea is simply to always have data waiting to be written to disk without delay, and how to balance the CPU’s ability to decompress with the network’s ability to transmit to many clients at once, and the FOG server’s ability to serve many clients at once. This all comes back to two simple things I think: Max Clients and compression rate.

It’s a balancing act of these two things. Of course, ZSTD is the most superior compression algorithm, which is why it’s not one of the two simple things. But it’s compression rate is.

The FOG Server’s disk does play a role - but at my last job, I was clearly hitting the network’s maximum throughput bottleneck - so a solid state disk would not have helped.

At any rate, the script below is an example of how to automate the monitoring & collecting of things from FOS: https://github.com/FOGProject/fog-community-scripts/blob/master/fogAutomatedTesting/postinit.sh
That’s what I’d use to collect any custom metrics you want to monitor more quickly, instead of doing a debug every time and manually monitoring.

@george1421 Yes, thank you george.

@george1421 ahah thanks really 😉

I will be back soon (tomorrow) for a new thread 😄
I used FOG since 3 years and this solution is beautiful !

@george1421 thank you so much 🙂
Have a good night 😉

@Tom-Elliott
I wasn’t aware that snapins automatically showed under the groups… If that’s the case then it kinda threw me for a loop. Now to recover from my own little screw up… oh well lesson learned… don’t be a dummy 🙂

@Quazz @kmstory
I do this already… here is my menu entry.

menu DBAN Nuke Menu item autonuke AutoNuke DoD 3-Pass item zero AutoNuke 1-Pass Zero Wipe item choose-disk Single Disk Selection item return Back to top menu... item choose --default return --timeout 10000 target && goto ${target} :autonuke kernel http://${fog-ip}/dban/dban.bzi nuke="dwipe --autonuke" silent vga=785 boot || goto failed :zero kernel http://${fog-ip}/dban/dban.bzi nuke="dwipe --autonuke --method zero" silent vga=785 boot || goto failed :choose-disk kernel http://${fog-ip}/dban/dban.bzi nuke="dwipe" silent vga=785 boot || goto failed :return chain ${boot-url}/service/ipxe/boot.php?mac=${net0/mac} || prompt goto MENU

As you can probably tell, from that menu, I have the DBAN iso extracted to this folder /var/www/html/dban/

Try it out… Works wonders for me.

Hi,

may something usefull inside:
https://forums.fogproject.org/topic/10392/audit-mode-no-changes-get-applied-to-default-profile/3

Regards X23

@Tom-Elliott Thanks!

@george1421 said in Storage Group Activity:

ask, (before you change this value) what is your goal here? Are you trying simultaneous deployments? Depending on your VM infrastructure, if you try to deploy more than 10 images from a single storage node at the same time you will run into VM resource constraints (i.e. network saturation, unable to move data fast enough from the vmdk file, and so on). So increasing this number will not improve performance, but actually hurt your overall deployment speed (IMO the default of 10 is too high to start with).
If you need to deploy more than 5 systems simultaneously (via unicast) I might consider switching over to multicast deployments. With a multicast deployment only a single image is transmitted over your network for any number of clients at the same time.
If you want to continue to use unicast imaging (because your network is multicas

Okay Thank You!

@gabbas If you were using the latest version of the new fog client, it will rename the object for you in active directory.

You probably can start here: https://docs.microsoft.com/en-us/internet-explorer/ie11-deploy-guide/enable-and-disable-add-ons-using-administrative-templates-and-group-policy

several different methods, enable all, auto enable, or enable by clsid done by GPO.

@TaTa said in DNSMASQ 2.76-5 on Jessie:

Has anyone tried this version on Jessie?

Yes, but not from the stretch repository. We have documentation on how to compile it for Debian 8 here: https://wiki.fogproject.org/wiki/index.php?title=ProxyDHCP_with_dnsmasq#Compiling_dnsmasq_2.76_if_you_need_uefi_support

In general, is it okay to use packages designed for Stretch on Jessie?

No idea. Try it on a test box. Worst thing that can happen is it doesn’t work, then you can come back here and let the world know. My personal advice though - don’t use Stretch packages on Jessie - just my 2 cents. They have two different names for a reason.

@Tom-Elliott said in Certificate expired FOG Website:

I’ve modified the cron to run every 5 days so this should no longer happen.

with letsencrypt i let the cron job run every 2 months (certs are valid for 90 days).
i would leave the cert server contacts as small as possible, for what should 5 days good for? 🙂
Sure, the best way in my mind would be 24 hours before it expires…

Regards X23

@george1421 said in UEFI Screen Size:

vga=792

That seems to work as expected. I will do some more extensive testing of it this afternoon if possible and report back.

@Quazz
The device is a Lenovo X1 Yoga Gen 2.

There are no other devices on the subnet. I have the server physically and logically separated from all other networks/devices in my scheme. I will disable secure boot and report back.

EDIT: Secure boot disabled is letting me boot to the FOG menu now. I just need to change the MENU EXIT TYPE I think. When I chose the Boot From Hard Disk option, I got a “Chainloading” failure. I think once I get that straightened out, it will work.

EDIT 2: I changed the option FOG_EFI_BOOT_EXIT_TYPE to REFIND_EFI and it was able to boot successfully from the FOG Menu.

@Tom-Elliott said in CentOS 7 Problems:

The really feels like a double installation almost. Though I don’t know quite how to describe it.

I’ve fresh installed CentOS with fog at least 5 times now and keep getting the same result
I attempted a fog installation with Archlinux as well and got this same result.
by fresh install, I mean wiping the hard drive completely and installing a brand new OS, then installing fog

@Tom-Elliott said in CentOS 7 Problems:

Also can you please check FOG Configuration Page->FOG Settings->Web Server->FOG_WEB_ROOT and make sure it’s not set to WEB_ROOT, aka please set to /fog/

0_1498592218897_bandicam 2017-06-27 14-35-18-036.jpg

@Tom-Elliott said in CentOS 7 Problems:

Are you doing any weird redirects? For example FOG is expecting to look to /var/www/html/fog (http://SomeIP/fog/)
But you have it set to go: http://someIP and it’s passing you to the fog site?

This is a clean install, I haven’t changed any settings that aren’t stock

Yes. In the hour field 0, 23/2

Are you sysprepping? Was the reference machine previously joined to the domain?

For your images, you should keep them pure - never capture a dirty image because it only causes problems. Pure means NEVER having been on the domain before, and as lean & clean as possible meaning not using old images to make new ones - keep your old images as backups, but build from scratch (installation media) every time - always delete old partitions and remake them, and capture new images.

At my old job, I would include month and year (not day) in my image names.

@Sebastian-Roth Multicasting is working, so I don’t think it was a port issue. I ended up making another session for those 6.

I had another session afterwards with 25 computers (different model) that worked.

Issue only observed on Dell OptiPlex 3020 so far.

@Wayne-Workman It works. At the end, it is very simple. I just uploaded the .exe file and added /silent under Snapin Arguments. It works very smoothly. Just for future reference for other users, installing Citrix receiver is also slimier method. ie. CitrixReceiver.exe /silent.

Thank you all. 👍 🙂