Categories

• Announcements

  Get the latest news on what's happening.
  167
  Topics
  702
  Posts

  S

  @astrugatch Quazz is spot on with what he says.
• General Topics

  View tutorials or talk about FOG in general.

  General

  Tutorials
  1956
  Topics
  15704
  Posts

  

  @fry_p ok now I think is time for some hokus-pokus magic without breaking much. From your production server export the image definitions and import them into your dev environment. From your production server export and then import the host definitions into the test setup. This will create a clone of your production environment without the image files. Temporarily move the production FOG server’s IP address (i.e. just swing it out of the way) and move the dev FOG client server’s IP address in place of the production fog server (understand this may impact pxe booting if you have them boot through FOG). The goal here is to apply real world loads to the FOG client server. We should watch the CPU usage on the FOG client server (we may need to increase the number of php-fpm workers to satisfy all of the requests) as well as the mariadb service on the dev imaging server. We are looking for high cpu usages on both systems. This might tell us if we need to spin off the sql server onto its own server. We should also gauge the web ui performance on the imaging server, because that was a pain point when you had the check in times set to the default. I’m not sure I’d leave the check in time at 30 seconds in a production environment, but it would be interesting to see the load. When you are done testing then swing the dev FOG client server out of the way and put the production fog server back in place.
• Technical Help

  Get help with your FOG system.

  FOG Problems

  Hardware Compatibility

  Windows Problems

  Linux Problems

  Mac Problems

  General Problems
  9318
  Topics
  91463
  Posts

  

  @f-an Did you install FOG using the git method or the tarball method? Because if you use the git method you can switch to the working branch and install fog 1.5.7.2 which addresses some issues since 1.5.7 GA was released. I’m not saying that solves anything also @Quazz was working on updated inits (FOS Linux virtual hard drive) with the updated version of partclone. That updated version I seem to remember fixed a slow nvme issue. Let me see if I can find the link he posted. Edit: Read the entire thread so you can see how to install the inits without breaking your fog deployment: https://forums.fogproject.org/topic/13620/very-slow-cloning-speed-on-specific-model/12 Upgrading to 1.5.7.2 is not required to test these inits.
• Developers

  Report bugs, request features, or get the latest progress.

  General

  Feature Request

  Bug Reports
  2037
  Topics
  19356
  Posts

  

  @p4cm4n said in Associate all new hosts with Snapin: assign template host to template group, assign properties to template host. No don’t do this because it will create a loop. The names have to be exactly the same that is all. Every host added to the template group will cause the database trigger to fire copying the host template settings over to the host just added to the group. nothing that was ‘set’ is actually ‘deployed’ but rather with the sql hack/trigger, its just a property of the host Its possible that the settings are made in the database but because of database caching the FOG application may not see the changes until the cache is refreshed. So are you saying that the settings on the template host are not being copied over (like OU or some other parameter field) or is this a question about the snapins not installing?