@Greg-Plamondon said in FOG User Tracking -Search:

what repo is 1.6 in?

should be able to do a git checkout working-1.6, if I recall.

Newly installed and updated Ubuntu 18.04 box throws a couple of error messages during fog installation
From foginstall.log:

 * Setting up and starting TFTP Server.........................Too few arguments.
 Too few arguments.
 OK
 * Setting up and starting VSFTP Server........................OK

Results in TFTP daemon not restarted after configuration change. Running configuration points to directory /var/lib/tftpboot. Configuration is corrected on service or server restart.

Traced to functions.sh#L458-L459

                systemctl is-active --quiet && systemctl stop tftpd-hpa >>$workingdir/error_logs/fog_error_${version}.log 2>&1 || true
                systemctl is-active --quiet && true || systemctl start tftpd-hpa >>$workingdir/error_logs/fog_error_${version}.log 2>&1

Probably should be:

                systemctl is-active --quiet tftpd-hpa && systemctl stop tftpd-hpa >>$workingdir/error_logs/fog_error_${version}.log 2>&1 || true
                systemctl is-active --quiet tftpd-hpa && true || systemctl start tftpd-hpa >>$workingdir/error_logs/fog_error_${version}.log 2>&1

I believe you are misunderstanding that result from df. That line says that there is a volume of size 88GB with a filesystem currently housing 33MB of data that is mounted under the directory /Images. Separating the content of /images (where FOG keeps the captured image data by default) is a common practice, but in your case it seems there may be a capital ‘i’ in the directory name. If you installed FOG without reusing the previous settings, it may be the case that you are not seeing all the space that was available to you previously due to this naming mismatch. If you want to use this volume for storing you images, you can change the location of the image store to /Images in your storage node configuration.

@dylan123
typically mariadb defaults to /var/lib/mysql/ for the data files.

It looks like your boot partition may be full. While this wouldn’t necessarily cause you issues with day to day operation, it can play havoc with apt if you have a kernel update in the queue when running updates. I have had more than several update sequences bork due to this, and depending on where it borked, I could see packages that have a number of dependencies such as mariadb being left in a non-startable state. I would suggest doing an apt autoremove to remove the unneeded kernels, but be aware you may need to manually give apt a little room in /boot by manually deleting an old kernel or two then running a apt -f install (I think) to cleanup from the dirty state. I believe Ubuntu generally keeps the current and one or two previous kernels by default.

If you want to see if this might be an issue prior to digging around, a apt upgrade should complain at you.

@Sebastian-Roth Nice call.
Installation, both under the auspices of a sudo su -l in terminal and as root through ARD, appear to be behaving after a manual kick to launchctl. The newest iMacs don’t seem to be triggering a pending host notification, but they are logging the communication on the client and in the apache logs. I suspect there might be too many mac addresses, but I am thinking that is a Monday problem.

@mikeakin44 and what happens if you make the same boot order change on your reference machine?

If you would please, answer the following:
Which boot method are you using (Legacy BIOS or UEFI)?
What is the boot order, or boot orders if there are separate sequences for normal, automatic, and error?
What are the settings for the image type and the partition targeted?
What is the content of the d*.partitions files in the folder for the acquired image?

hmm, must have missed that one. Last commit I see on zazzles was for some library updates. Don’t see any specific references to service stops on 1903 in the commit notes , but could be related. Don’t see any commit notes regarding service stops on fog-service either.

Were you thinking of https://forums.fogproject.org/topic/13704/fog-service-quits-running ?

@Sebastian-Roth I have a couple units I can probably play with and might be able to find a little time to cobble something together.

Installing the release msi interactively and targeting a non-https FOG installation is successful and functions as expected on one of my test systems, so I don’t think there is anything inherently wrong with the installation logic. Going to spin up an https fog instance to test against

@TaTa The data being pulled in for the password is out of urandom, so it is not implausible that, as the log indicates, a given line may not include a digit or upper case letter. You may be able to run the installer a few more times and get a random password that conforms to the system’s password requirements. You may also be able to create a partial /opt/fog/.fogsettings with strong passwords compliant with your systems password policies. Format and settings are available in the Wiki. I haven’t tested this, but my understanding is that anything not set in .fogsettings is requested by the installer.

Edit: the setting you are likely interested in is password=.

May also want to check to see if the computer object already exists in AD. If the account does exist, the join account also needs the ability to modify that account either by virtue of being the creator/owner or by having the permission to modify computer objects in the target OU.

@UWPVIOLATOR If you can’t get the application to behave with respect to the restarts, you could always create a snapin pack bundling the executable with a script. In the script, you could check to see if the application was already installed and of the correct version, then if it wasn’t perform the install. if you wanted to kick off the application and then do something like loop while the executable was running, you might want to play with the start command, something like start "" installer.exe -args. https://ss64.com/nt/start.html

@george1421 the /k flag runs the specified command then leaves the command window open. https://ss64.com/nt/cmd.html

@nonamejason The means by which interface addressing is managed by default has changed a number of times over the years. Which version of Ubunutu Server is this box and how did you add in the 20.31 address?

When confirming your task you are presented three options for scheduling: Instant, Delayed, and Schedule Cron-style. It sounds like you want the last option.

The smart installer is capable of installing the fog client on Windows, macOS, and Linux.

@Sebastian-Roth Looks good from this end.

I believe you are misunderstanding that result from df. That line says that there is a volume of size 88GB with a filesystem currently housing 33MB of data that is mounted under the directory /Images. Separating the content of /images (where FOG keeps the captured image data by default) is a common practice, but in your case it seems there may be a capital ‘i’ in the directory name. If you installed FOG without reusing the previous settings, it may be the case that you are not seeing all the space that was available to you previously due to this naming mismatch. If you want to use this volume for storing you images, you can change the location of the image store to /Images in your storage node configuration.

Do you have your network configured for Gigabit ethernet to the client and server? The magnitude of that change that sounds suspiciously like a change in media speed someplace down to 100MBit.
Are these unicast or multicast deployments?
Have there been any changes to the network infrastructure or switch configuration?
Are you able to see if your switches are auto-negotiating to the correct speed with the clients you are deploying, the fog server, and any intermediary switches?

The process you describe is the intended behavior, but I believe @george1421 worked on a persistent group plugin. Have a look through https://forums.fogproject.org/topic/8836/basic-persistent-groups-and-1-3-0rc16 a read through and see if it matches what you are attempting. I haven’t played with persistent groups personally, but the plugin is in the menus under version 1.5.7

@fogusnew If you have the fog client installed in a sysprepped image you are deploying, the fogservice should be disabled prior to the sysprep.
https://wiki.fogproject.org/wiki/index.php/FOG_Client#FOG_Client_with_Sysprep
I wouldn’t think this would present intermittently in one room but not another, but I have seen weirder things happen. You might want to recapture with the fog service disabled and the service start configured in SetupComplete.cmd and reattempt the deployment and see how things behave then.