Categories

• Announcements

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

  

  Well done lads!
• General Topics

  View tutorials or talk about FOG in general.

  General

  Tutorials
  1903
  Topics
  15356
  Posts

  

  Under Construction Postinit scripts are scripts called by FOS just after the FOS Linux system inits and before the main FOS imaging program starts. The postinit scripts give us the opportunity to make adjustments to FOS before imaging occurs. These adjustments can be to initialize raid controllers, bring up specialized hardware, or in the case of this post replace or patch parts of FOS imaging scripts before imaging begins. One example of patching or replacing FOS components might be if you wanted a customized registration process. The FOG registration process is managed by a FOG script called fog.man.reg that’s located in the /bin in the inits. One way to update this fog.man.reg files is by unpacking the inits, updating the script and then repacking the inits and then moving the inits to the proper location on the FOG server. Instructions on unpacking and packing the inits can be found in the FOG Wiki page here The method I’m going to cover here is to place the updated fog.man.reg file on the FOG server in the /images/dev/postinit script directory where FOS Linux will see it and execute the postinit script before it starts imaging. Create a file /images/dev/postinit/fog.patch.man.reg Paste the contents below into fog.patch.man.reg # Current File in FOS Linux to be replaced currfile="/bin/fog.man.reg" #Patch file to send to FOS Linux virtual hard drive newfile="${postinitpath}fog.reg.man.fix" # --------------------------------------------- # DO NOT edit any text below this line # --------------------------------------------- . /usr/share/fog/lib/funcs.sh echo "Testing path for our fixed file at ${newfile}" debugPause # Test path and run copy if found and matched. if [[ -r $newfile ]]; then echo "Found source file preparing to copy" debugPause cp -f $newfile $currfile >/dev/null 2>&1 [[ ! $? -eq 0 ]] && echo "Copy Failed" || echo "Copy Succeeded" debugPause else echo "Failed to find file [${newfile}] sorry. Copy Failed" debugPause fi Make the script executable chmod 755 /images/dev/postinit/fog.patch.man.reg Edit '/images/dev/postinit/fog.postinit` Add the following line to the bottom of the fog.postinit script . ${postinitpath}fog.patch.man.reg note: that leading period is not a mistake it needs to be the first character on that line. Its (dot)(space)${postinitpath} to ensure your custom patch script is called correctly. <I stopped here for script validation> Original script credit Tom Elliot ref: https://forums.fogproject.org/topic/9754/custom-full-host-registration-for-1-3-4/46
• Technical Help

  Get help with your FOG system.

  FOG Problems

  Hardware Compatibility

  Windows Problems

  Linux Problems

  Mac Problems

  General Problems
  9065
  Topics
  89021
  Posts

  

  I don’t think this is a fog issue, specifically. BUT lets look at it a bit more. FOG uses ftp to move files between the master node and the storage nodes. Specifically it uses the lftp utility. One of the parameters of the lftp program is bandwidth throttling (which one I don’t remember off the top of my head). Now I “think” in the fog replicator logs it will show you the lftp command with its calling parameters. Lets see if that bandwidth switch is set. If you can’t find it in the logs, when the replicator is running you can use this command to capture the lftp command and its parameters ps aux|grep lftp A ftp process needs to be happening at the exact time you run the ps command to get the parameters. So the first step is just to see if FOG is misbehaving poorly. The next step is to probably test by manually ftping a 100MB or larger file from the fog server to a storage node. Its possible that a change in the network infrastructure has slowed the ftp process.
• Developers

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

  General

  Feature Request

  Bug Reports
  2021
  Topics
  19199
  Posts

  A

  On the Advanced Task page, this wording under All Snapins does not suggest only assigned snapins will be installed: This option allows you to send all the snapins to host without imaging the computer... could instead say: This option allows you to send all the snapins which are assigned to the host without imaging the computer... Also, to offer clearer indication to persons attempting to push snapins to an existing PC, add a pop-up or append to the existing “Host Update Success” popup a message such as: Note: to deploy these snapins to an existing image with the FOG service running, click the "All Snapins" link under Basic Tasks -> Advanced to create the task.