• Recent
    • Unsolved
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Register
    • Login
    1. Home
    2. Tom Elliott
    • Profile
    • Following 27
    • Followers 83
    • Topics 140
    • Posts 19,330
    • Groups 0

    Tom Elliott

    @Tom Elliott

    5.1k
    Reputation
    39.0k
    Profile views
    19.3k
    Posts
    83
    Followers
    27
    Following
    Joined
    Last Online

    Tom Elliott Unfollow Follow

    Best posts made by Tom Elliott

    • Gratitudes

      I know I’ve been out of this for a little bit. I check in here or there, but just been extremely busy.

      I don’t want to stop contributing, I just am taking time for myself after my workly duties.

      I have to give a big gratitude and thanks for everyone here trying to help out whether by code, by helping the rest of the community, or documentation.

      @Sebastian-Roth I know you’re busy but you’ve kept the project rolling even with the minimal availability you have. Thank you.
      @george1421 I’m sure you’re busy, but I still see you posting and helping where possible and amenible. Thank you.
      @Wayne-Workman I know you’re helping where you can as well. (Of course I can’t exactly post everybody because I’ve been busy and honestly not keeping up with the forums as much as I probably should.)

      @everyone Thank you. Thank you for still believing in this project. We’re doing the best with what we have. Please understand in we’re lacking, it’s most likely unintentional. I know I’m just busy.

      posted in Announcements
      Tom ElliottT
      Tom Elliott
    • FOG 1.3.5 and Client 0.11.11 Officially Released

      https://news.fogproject.org/fog-1-3-5-and-client-0-11-11-officially-released/

      posted in Announcements
      Tom ElliottT
      Tom Elliott
    • FOG 1.5.0 RC 11

      https://news.fogproject.org/fog-1-5-0-rc-11/

      posted in Announcements
      Tom ElliottT
      Tom Elliott
    • Ubuntu is FOG's enemy

      TLDR; Rerun the fog installer if you have lost “Database Connectivity” to your fog server, or run the ALTER USER syntax shown below.

      So Ubuntu 16, among others I suppose, enable a “security updates” to be applied automatically as a “default” to things. Why, well it makes it simpler to ensure your Ubuntu systems are in compliance and patched for any potential exploits. This causes unknown and unexpected issues.

      I figured it’d be a safe thing to express that there could be problems (as many of you have already experienced) that when these updates go up (with or without your knowledge) it can break functionality in unexpected and inopportune ways.

      The quickest fix is to simply rerun the fog installer which should correct the problem.

      As a note, it seems this problem is specific only when the mysql account is the 'root' user AND the password is blank.

      The “fix” if you must do it manually is to open a terminal and obtain root:
      Super (Windows Key) + T then sudo -i (in most cases).

      From there, open mysql with mysql -u root

      NOTE: MySQL MUST be run with ROOT.

      Run:

      ALTER USER 'root'@'127.0.0.1' IDENTIFIED WITH mysql_native_password BY ''; AND
      ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '';

      It’s okay if one of them fails. This is going to fix Most people’s issues.

      I would highly recommend removing the unattended-upgrades as many of these “sudden” issues came as a security patch ubuntu pushed out. By default Ubuntu typically set’s this for you as enabled and it can cause havoc on you as you (the admin) may not have “done” anything.

      To prevent this problem from happening in the future you could run:

      apt-get -y remove unattended-upgrades (AS Root again).

      posted in Announcements
      Tom ElliottT
      Tom Elliott
    • FOG Activity - Status

      FOG is still actively being developed. It’s not necessarily readily apparent, but we can assure you things are still being worked on. These updates may not be communicated in a way that everybody just knows, but can easily be seen if one were to look at our repository site.

      Between our own schedules and lives, we can get very busy. We try to keep things updated and help out on the forums even during lull periods. This might mean we aren’t pushing an RC or release as frequently. It may mean we’re working on other things for the project, such as can be seen if looking at our github site.

      Our forums are heavily active, and this should point as an indicator to our “status” as well.

      If anybody would like to see an increase in developers donating their time to making this free software, consider donating either with monetary support or by spending personal time to help with development.

      FOG is an open source project - it’s even in the name. It is driven by people donating their time and resources. The releases of FOG revolve around when developers can spare a few hours throughout the week. Sometimes that will mean releases will be further, sometimes that will mean releases will be faster. That’s just the nature of our project, and many other open source projects.

      posted in Announcements
      Tom ElliottT
      Tom Elliott
    • I'm away, but back?

      Hey everybody,

      I know you see me here on occasion from time to time. Life decisions have made it more difficult for me to do things I would normally be doing. Rest assured, I am still around, and while I’m not quite as active as I was in the past, it’s not because I don’t want to be.

      I had to move, and as part of that I have none of my normal development stuff readily available. Part of the move made me not have a laptop, until today.

      I need to setup my dev environment again, so it may take a little bit, but I will be back up.

      posted in Announcements
      Tom ElliottT
      Tom Elliott
    • FOG 1.5.10.41 and forward

      https://news.fogproject.org/fog-1-5-10-41-officially-released/

      While this maybe spur of the moment, it should officially release 1.5.10 with all relevant bug/security fixes encapsulated (among a few other features.)

      This has brought a new methodology of releases in that bug/security releases should be done much more regularly.

      dev-branch, historically, was a place where new development occurred (hence its name) but over the last couple of years or so it’s mainly been a bug/security thing, not really a true development approach.

      This is OKAY, in my head. Why:

      Well we have the master branch which is the ‘baseline’ of a verions. We have the dev-branch, which allows us to work on bugs/security issues. We have the working branches for what will eventually become master. Working is our “dev branch” but keeps proper seperation of things in my opinion.

      Basically:
      master -> basis for dev-branch (which merges into stable on a regular cadence - still being worked out)
      working -> basis of forward development

      So we effectively have:
      production
      staging
      development well seperated.

      THis may mean on the regular automated releases, no announcement or news article will be created, and I think that’s okay.

      Hopefully exciting we have a release after 1.25 years 🙂

      Thank you!

      posted in Announcements
      Tom ElliottT
      Tom Elliott
    • RE: Release plan for FOG

      That’s correct. The main reason fog is constantly moving forward is because the codebase is improved upon. Major bugs tend to be addressed for the next release. We don’t do an LTS because there’s really two main people working on fog in a consistent manor. Those two are @Joe-Schmitt and myself. Debian and Libreoffice have the team too be able to perform such a feat. Their product is Opensource but they have an employment team which can afford them that luxury. FOG has a team but we make no money and as such are required to work full time jobs. We work on FOG in our free time. I’ve had the ability to even work on it from work because we used the software.

      Maintaining many different versions is difficult. And we don’t have a support team. WYSIWYG and I think we’ve done pretty well on support, even if we don’t have the ability to do dedicated support for our product. 1.5 was a major step toward modernizing the GUI. 1.6 will vastly improve on this. It was only recently we kind of came up with a road map on how best to proceed. Of note, 1.5 will be maintained until 1.6 is released. 1.6 is focused on making he GUI much more modern. 1.7 will be focused mostly toward fixing and refactoring the FOG client. 1.8 will focus on making the FOS system more modular and usable. I don’t know yet for 1.9. 2.0 will bridge the gap for our rewrite based on the work from 1.5 and up. While we do plan to try to do backports where possible, it’s much easier to ask people to update to the latest version than it is to try to maintain many different versions with backports in mind. At least for what FOG does.

      I doubt this will appease anybody, but it’s what I think needs to be said. We are working hard and provide support for our product as best we can. The community makes fogs support system, I think, one of the best around. Add to that and you can almost always have a developer working side by side to help and fix issues as they come up, I don’t think it’s unfair to ask users to update to a specific version. Even if there are bugs, we will always try to correct what we can, when we can. (And normally it’s a pretty quick turn around).

      I’m not perfect and I’ll give you that. We don’t even have a test suite to know if things are working as intended. We have to rely on the community and suggestions are great, just understand our answers won’t always be what people want to hear.

      posted in Feature Request
      Tom ElliottT
      Tom Elliott
    • FOG 1.4.0 Officially Released

      https://news.fogproject.org/fog-1-4-0-officially-released/

      posted in Announcements
      Tom ElliottT
      Tom Elliott
    • FOG 1.4.4 Officially Released

      https://news.fogproject.org/fog-1-4-4-officially-released/

      posted in Announcements
      Tom ElliottT
      Tom Elliott

    Latest posts made by Tom Elliott

    • RE: Fog 1.6.14 Driver Replication Issue

      @FlareImp That message is a warning, not a failure. The install continues past it. It does not affect replication.

      1.6 lets a storage node ask the main server for a web certificate signed by the main server’s CA. The CA permits only names in the main server’s own domain. Your main server is named tv-fog-main with no domain, so no node name fits, and the main server declines. The node then keeps its own self-signed certificate. That is what storage nodes have always used, and the installer prints “Skipped” and says so on the next lines.

      You do not need to do anything about it. Continue with the update on the other nodes. When all servers run dev-branch, enable the replicators on the storage nodes again and check one cycle of /opt/fog/log/fogreplicator.log on N01. It should now say “This is not the master node” instead of “We are node ID: 1”.

      posted in FOG Problems
      Tom ElliottT
      Tom Elliott
    • RE: Fog 1.6.14 Driver Replication Issue

      @FlareImp A correction to my last post: the fix is already in dev-branch. You do not need to wait for the next release. To use it now, update the main server and every storage node from dev-branch:

      cd /path/to/your/fogproject/checkout
      git fetch
      git checkout dev-branch
      git pull
      cd bin
      sudo ./installfog.sh -y
      

      Update every server, because the bug is on each node. After all of them run the new version, you can enable the replicators on the storage nodes again.

      posted in FOG Problems
      Tom ElliottT
      Tom Elliott
    • RE: Fog 1.6.14 Driver Replication Issue

      @FlareImp Thanks, that log shows the cause. Every cycle on TVNE-Fog-N01 starts with:

      We are node ID: 1. We are node name: TV-Fog-Main
      

      So N01 runs replication as if it were your main server. N01 has short copies of the large files, and every hour it pushes them to TVAE-Fog and TVNE-Fog. For example, it sends d1p3.img at 1323409736 bytes over the full 22556692664 byte file. That is the copy you saw, and that is why both nodes show the same short sizes. Your main server then deletes the short file and starts again, and the cycle repeats.

      This is a bug in 1.6. Each FOG server adds the FOG_WEB_HOST address (your main server) to the list of its own addresses. So every storage node matches the main server’s storage node entry and acts as the main server. 1.5 does not do this, which is why 1.5 replicated correctly. The fix is done and will be in the next release.

      The same bug explains the files that vanished during your rsync. A server that acts as the main server deletes each file on the other nodes that it does not have itself. While the rsync ran, N01 did not yet have the Win11_25H2_Smart26 files. So N01’s replicator deleted them on TVNE-Fog. To confirm, look in /opt/fog/log/fogreplicator.log on N01 for “File does not exist on master node, deleting” lines that name TVNE-Fog.

      Until the fix is released, stop the replicators on every storage node, but not on the main server:

      sudo systemctl stop FOGImageReplicator FOGSnapinReplicator
      sudo systemctl disable FOGImageReplicator FOGSnapinReplicator
      

      Run that on TVAE-Fog, TVNE-Fog and all four N01/N02 nodes before you copy anything else. Then start the replicator on the main server. It replaces the short and missing files on TVAE-Fog and TVNE-Fog, Win11_25H2_Smart26 included, on its next cycles. Leave N01 and N02 disabled in Storage Management until the fix is out, because their copies are short too.

      posted in FOG Problems
      Tom ElliottT
      Tom Elliott
    • RE: Fog 1.6.14 Driver Replication Issue

      @FlareImp Thanks. The main server has the full file (1692345974 bytes). The node tvne-fog has a short copy (1558966032 bytes), and the log shows that same short size every hour. A copy that is still running would show a different size each time. So something writes the same short file to the node again and again.

      The copy you saw from the other node is the likely source. Only a node marked as master runs replication. A master sends to every other enabled node in its own storage group, even to another master. If that node is also marked master and has a short copy of the file, it overwrites the copy on tvne-fog each cycle.

      Can you check these:

      • Storage Management: list each storage node, its storage group, and whether “Is Master Node” is checked.
      • On the node you saw copying: ls -l /images/Drivers/Latitude3500/win11/
      • On the same node: the top of /opt/fog/log/fogreplicator.log for one cycle. It shows which nodes that node sends to.

      If that node is a master in the same group as tvne-fog, uncheck “Is Master Node” on it. A storage group must have only one master.

      posted in FOG Problems
      Tom ElliottT
      Tom Elliott
    • RE: Fog 1.6.14 Driver Replication Issue

      @FlareImp Thanks, that copy in the other direction is a good clue. The log shows two separate problems.

      1. A file name with a space is never seen on the storage node. For example, “7450 AIO-WIN11-A10-YHP57.CAB” shows a size of 0 on the node every cycle, so the replicator deletes it and copies it again. This is a bug in how FOG reads the node’s FTP listing, and a fix is on the way. Until then, renaming those files without spaces stops the loop for them.

      2. Files without a space, such as win11/3500-win11-A00-YH77C.CAB, show the same smaller size on both nodes every hour. A copy from the other node back toward your main server would explain that. Each storage group’s master sends an image to the other groups only when its own group is that image’s primary group. If another group’s master also sends the image, the two copies overwrite each other.

      Can you check these for one affected image, such as Drivers_Latitude3500:

      • Image Management > Drivers_Latitude3500 > Storage Groups tab: which group is marked primary?
      • Storage Management: for each storage group, which node is the master? Is the node you saw copying marked as a master?
      • ls -l /images/Drivers/Latitude3500/win11/ on the main server and on that node.
      posted in FOG Problems
      Tom ElliottT
      Tom Elliott
    • RE: Fog 1.6.14 Driver Replication Issue

      @FlareImp Thanks, the log shows the cause. 1.6.0.14 has a replication bug: the check for a transfer that is still running never matched. So each cycle compared the files while lftp was still copying them. It saw the half-copied file on the node, logged “File size mismatch”, deleted it, and started the copy again. A large file over your rate-limited link never finished. That is why rsync worked and the replicator did not.

      1.6.0.158 fixes this. Please update the master and every storage node to 1.6.0.158, then turn the replicator back on.

      The “File does not exist win11” lines are the subfolder name, not a missing file. 1.5 logs the same lines. They make lftp run once per cycle, but it copies nothing when the files already match.

      posted in FOG Problems
      Tom ElliottT
      Tom Elliott
    • RE: Using FOG Postinstall scripts for Windows Driver injection 2017 ed.

      I just wanted to add some updates as 1.6 being released and with advent of Win 11 now.

      Wanted to have more capable set of scripts here. I know the thread is very old, but it’s still worth the update in my book.

      /images/postdownloadscripts/fog.postdownload

      #!/bin/bash
      . /usr/share/fog/lib/funcs.sh
      [[ -z $postdownpath ]] && postdownpath="/images/postdownloadscripts/"
      # FOS sets osClass from the image's OS (determineOS, FOS 20261110 or later).
      # On an older FOS kernel osClass is empty, so derive it from the osid.
      if [[ -z $osClass ]]; then
          case $osid in
              5|6|7) osClass="win7" ;;
              9|10|11) osClass="winmodern" ;;
          esac
      fi
      case $osClass in
          win7|winmodern)
              clear
              [[ ! -d /ntfs ]] && mkdir -p /ntfs
              getHardDisk
              if [[ -z $hd ]]; then
                  handleError "Could not find hdd to use"
              fi
              getPartitions $hd
              for part in $parts; do
                  umount /ntfs >/dev/null 2>&1
                  fsTypeSetting "$part"
                  case $fstype in
                      ntfs)
                          dots "Testing partition $part"
                          ntfs-3g -o force,rw $part /ntfs
                          ntfsstatus="$?"
                          if [[ ! $ntfsstatus -eq 0 ]]; then
                              echo "Skipped"
                              continue
                          fi
                          if [[ ! -d /ntfs/windows && ! -d /ntfs/Windows && ! -d /ntfs/WINDOWS ]]; then
                              echo "Not found"
                              umount /ntfs >/dev/null 2>&1
                              continue
                          fi
                          echo "Success"
                          break
                          ;;
                      *)
                          echo " * Partition $part not NTFS filesystem"
                          ;;
                  esac
              done
              if [[ ! $ntfsstatus -eq 0 ]]; then
                  echo "Failed"
                  debugPause
                  handleError "Failed to mount $part ($0)\n    Args: $*"
              fi
              echo "Done"
              debugPause
              . ${postdownpath}fog.copydrivers
              # . ${postdownpath}fog.updateunattend
              umount /ntfs
              ;;
          *)
              echo "Non-Windows Deployment"
              debugPause
              return
              ;;
      esac
      

      /images/postdownloadscripts/fog.copydrivers

      #!/bin/bash
      ceol=`tput el`;
      manu=`dmidecode -s system-manufacturer`;
      dots "Identifying hardware"
      case $manu in
          [Ll][Ee][Nn][Oo][Vv][Oo])
              machine=$(dmidecode -s system-version)
              ;;
          *I[Nn][Tt][Ee][Ll]*)
              # For the Intel NUC and intel mobo pick up the system type from the
              # baseboard product name
              machine=$(dmidecode -s baseboard-product-name)
              ;;
          *)
              # Dell and everything else
              machine=$(dmidecode -s system-product-name)
              ;;
      esac
      
      # if the machine isn't identified then no need to continue with this script, just return to caller
      if [[ -z $machine ]]; then
          echo "Unable to identify the hardware for manufacturer ${manu}";
          debugPause;
          return;
      fi
      echo "${machine} Identified";
      
      # Remove spaces from the machine name, works better with path definitions
      machine="${machine//[[:space:]]/}"
      
      dots "Verifying we've found the OS disk"
      if [[ ! -d /ntfs/windows && ! -d /ntfs/Windows && ! -d /ntfs/WINDOWS ]]; then
          echo "! OS root Not found !";
          debugPause
          return;
      fi
      echo "Found";
      
      dots "Verifying target Arch"
      system64="/ntfs/Windows/SysWOW64/"
      [[ ! -d $system64 ]] && arch="x86" || arch="x64"
      echo "${arch} found";
      
      debugPause
      
      # Build the OS folder name from osname, which FOS sets from the image's OS.
      # "Windows 10" becomes win10, "Windows 8.1" becomes win8.1, "Windows 11"
      # becomes win11. So the folder names from the old osid table still match.
      osn="${osname,,}"
      osn="${osn//[[:space:]()]/}"
      osn="${osn/windows/win}"
      
      dots "Preparing Drivers"
      clientdriverpath="/ntfs/Drivers"
      remotedriverpath="/images/drivers/$machine/$osn/$arch"
      
      debugPause
      
      if [[ ! -d "${remotedriverpath}" ]]; then
          echo "failed";
          echo " ! Driver package not found for ${machine}/$osn/$arch ! ";
          debugPause;
          return;
      fi
      echo "Ready";
      
      debugPause
      
      [[ ! -d $clientdriverpath ]] && mkdir -p "$clientdriverpath" >/dev/null 2>&1
      echo -n "In Progress"
      
      rsync -aqz "$remotedriverpath" "$clientdriverpath" >/dev/null 2>&1
      
      [[ ! $? -eq 0 ]] && handleError "Failed to download driver information for [$machine/$osn/$arch]"
      
      debugPause
      
      # Windows 7, 8 and 8.1 only. Windows 10 and later read the OEM driver path
      # from the unattend.xml, so they skip the registry edit.
      [[ $osClass != win7 ]] && return
      
      regfile="/ntfs/Windows/System32/config/SOFTWARE"
      key="\Microsoft\Windows\CurrentVersion\DevicePath"
      devpath="%SystemRoot%\DRV;%SystemRoot%\inf;";
      reged -e "$regfile" &>/dev/null <<EOFREG
      ed $key
      $devpath
      q
      y
      EOFREG
      

      /images/postdownloadscripts/fog.updateunattend

      #!/bin/bash
      # Sets the computer name and, for a host with "Join Domain" on, the domain
      # join in the deployed image's unattend.xml. fog.postdownload sources this
      # file with the Windows partition mounted on /ntfs.
      #
      # FOG sends these from the host record (service/hostinfo.php):
      #   hostname                      the host name
      #   hostusead                     1 when "Join Domain after deploy" is on
      #   hostaddomain, hostadou        the domain and the OU
      #   hostaduser, hostadpass        the join account and its password
      # hostadpass is empty unless FOG Configuration > FOG Settings >
      # FOG_HOSTKEY_ALLOWED_SOURCES lists the imaging network. The FOG Agent,
      # and the older FOG Client, join the domain without writing the password
      # to disk. Use this only where neither is installed.
      
      # Escape a value for XML text, then for the right side of a sed s|||.
      # The quoted replacements stop bash 5.2 from reading & as "the match".
      xmlEscape() {
          local s="$1"
          s="${s//&/'&amp;'}"
          s="${s//</'&lt;'}"
          s="${s//>/'&gt;'}"
          s="${s//\"/'&quot;'}"
          s="${s//\'/'&apos;'}"
          printf '%s' "$s"
      }
      sedEscape() {
          local s="$1"
          s="${s//\\/'\\'}"
          s="${s//|/'\|'}"
          s="${s//&/'\&'}"
          printf '%s' "$s"
      }
      xmlValue() {
          sedEscape "$(xmlEscape "$1")"
      }
      
      # The places Windows Setup reads an unattend.xml from after sysprep. The
      # [x] in each name makes it a glob, so nocaseglob matches any case of it.
      shopt -s nocaseglob nullglob
      unattends=(
          /ntfs/[w]indows/[p]anther/[u]nattend.xml
          /ntfs/[w]indows/[p]anther/[u]nattend/[u]nattend.xml
          /ntfs/[w]indows/[s]ystem32/[s]ysprep/[u]nattend.xml
          /ntfs/[u]nattend.xml
      )
      shopt -u nocaseglob nullglob
      if [[ ${#unattends[@]} -eq 0 ]]; then
          echo " * No unattend.xml found, skipping"
          debugPause
          return
      fi
      
      # A PXE boot does not carry the AD values on the kernel command line. Ask the
      # server for them, the same way FOS does after a USB boot. Keep only the
      # host* lines of the reply, and delete the reply because it holds the password.
      if [[ -z $hostusead ]]; then
          curlcmd=(curl -Lks)
          command -v fog.curl >/dev/null 2>&1 && curlcmd=(fog.curl -Ls)
          sysuuid=$(dmidecode -s system-uuid)
          sysuuid=${sysuuid,,}
          [[ -z $mac ]] && mac=$(getMACAddresses)
          token=$("${curlcmd[@]}" --data "mac=$(echo $mac | base64)" "${web}status/hostgetkey.php")
          "${curlcmd[@]}" -o /tmp/hinfo.txt --data "sysuuid=${sysuuid}&mac=${mac}&hosttoken=${token}" "${web}service/hostinfo.php" -A ''
          if [[ -f /tmp/hinfo.txt ]]; then
              . <(grep -E '^\[\[ -z \$host[a-z]+ \]\] && export host[a-z]+=' /tmp/hinfo.txt)
              rm -f /tmp/hinfo.txt
          fi
      fi
      
      joinDomain=""
      if [[ $hostusead == 1 && -n $hostaddomain ]]; then
          if [[ -z $hostadpass ]]; then
              echo " * No domain join password received, so the domain join is skipped."
              echo "   Set FOG_HOSTKEY_ALLOWED_SOURCES to the imaging network to send it."
              debugPause
          else
              joinDomain=1
              # Qualify a bare user name with the domain: DOMAIN\user.
              joinUser="$hostaduser"
              [[ $joinUser != *\\* && $joinUser != *@* ]] && joinUser="${hostaddomain}\\${joinUser}"
          fi
      fi
      
      name=$(xmlValue "$hostname")
      for unattend in "${unattends[@]}"; do
          dots "Writing Computer Name to $unattend"
          sed -i "s|<ComputerName>[^<]*</ComputerName>|<ComputerName>${name}</ComputerName>|g" "$unattend"
          if [[ ! $? -eq 0 ]]; then
              echo "Failed"
              debugPause
              handleError "Failed to update $unattend"
          fi
          echo "Done"
          debugPause
          [[ -z $joinDomain ]] && continue
          dots "Setting the domain join in $unattend"
          # Username and Password change only inside <Credentials>. AutoLogon and
          # the local accounts use the same element names.
          sed -i \
              -e "/<JoinWorkgroup>/d" \
              -e "/<Credentials>/,/<\/Credentials>/s|<Password>[^<]*</Password>|<Password>$(xmlValue "$hostadpass")</Password>|" \
              -e "/<Credentials>/,/<\/Credentials>/s|<Username>[^<]*</Username>|<Username>$(xmlValue "$joinUser")</Username>|" \
              -e "s|<MachineObjectOU>[^<]*</MachineObjectOU>|<MachineObjectOU>$(xmlValue "$hostadou")</MachineObjectOU>|g" \
              -e "s|<JoinDomain>[^<]*</JoinDomain>|<JoinDomain>$(xmlValue "$hostaddomain")</JoinDomain>|g" \
              "$unattend"
          if [[ ! $? -eq 0 ]]; then
              echo "Failed"
              debugPause
              handleError "Failed to set the domain join in $unattend"
          fi
          echo "Done"
          debugPause
      done
      
      posted in Tutorials
      Tom ElliottT
      Tom Elliott
    • RE: Fog 1.6.14 Driver Replication Issue

      @FlareImp Thanks for the details. Each “File does not exist” line in the Image Replicator log names the file the replicator could not find on the storage node. Can you post the following:

      • One full replication cycle from the Image Replicator log (FOG Configuration > Log Viewer), including the “File does not exist” lines.
      • The FOG version on each storage node that receives the driver folders. Do any of them still run 1.5?
      • For one file that the log names, the ls -la output for that file on the master node and on the storage node.
      posted in FOG Problems
      Tom ElliottT
      Tom Elliott
    • RE: 1.6.0.14: Web UI not staying signed in?

      @Shuttleu The fix is now in stable release 1.6.0.158. Update to it, and remember me should work appropriately.

      posted in FOG Problems
      Tom ElliottT
      Tom Elliott
    • RE: 1.6.0.14: "Create new tasking" modal hangs on "Loading, please wait..." if the host has no image

      @lperoma The fix is now in stable release 1.6.0.158. Update to it, and a refused task shows its reason in the modal instead of hanging on “Loading, please wait…”.

      posted in FOG Problems
      Tom ElliottT
      Tom Elliott