See last time a computer checked into FOG

[astrugatch]

Is there a way to see the last time one of my enrolled computers communicated with FOG? I have some machines that seem. have stopped communicating and I don’t have a good way of confirming if that’s true or not short of sending a snapin and waiting to see if succeeds.

[Sebastian Roth]

@astrugatch Do you have access to the hidden C$ share on that Windows machine? That way you could easily check the fog-client log file.

The other way you can go is grep "x.x.x.x" /var/log/apache2/access_log | tail on the FOG server console. That should give you the last 10 times contact to the FOG server from this client. Though interpreting the log output so you know for sure the communication is fine is another challenge. Post the output if you need help with it.

[astrugatch]

@Sebastian-Roth

Not sure why I am seeing this,

fogadmin@fogimaging:/var/log/apache2$ ls
access.log        access.log.2.gz  access.log.9.gz  error.log.14.gz  error.log.8.gz                 other_vhosts_access.log.13.gz  other_vhosts_access.log.7.gz
access.log.1      access.log.3.gz  error.log        error.log.2.gz   error.log.9.gz                 other_vhosts_access.log.14.gz  other_vhosts_access.log.8.gz
access.log.10.gz  access.log.4.gz  error.log.1      error.log.3.gz   other_vhosts_access.log        other_vhosts_access.log.2.gz   other_vhosts_access.log.9.gz
access.log.11.gz  access.log.5.gz  error.log.10.gz  error.log.4.gz   other_vhosts_access.log.1      other_vhosts_access.log.3.gz
access.log.12.gz  access.log.6.gz  error.log.11.gz  error.log.5.gz   other_vhosts_access.log.10.gz  other_vhosts_access.log.4.gz
access.log.13.gz  access.log.7.gz  error.log.12.gz  error.log.6.gz   other_vhosts_access.log.11.gz  other_vhosts_access.log.5.gz
access.log.14.gz  access.log.8.gz  error.log.13.gz  error.log.7.gz   other_vhosts_access.log.12.gz  other_vhosts_access.log.6.gz
fogadmin@fogimaging:/var/log/apache2$ sudo grep "x.x.x.x" access_log | tail
grep: access_log: No such file or directory

[astrugatch]

@Sebastian-Roth

Got into one of the shares and see this:

 9/17/2019 11:22 AM Client-Info Client Version: 0.11.16
 9/17/2019 11:22 AM Client-Info Client OS:      Windows
 9/17/2019 11:22 AM Client-Info Server Version: 1.5.7
 9/17/2019 11:22 AM Middleware::Response ERROR: Unable to get subsection
 9/17/2019 11:22 AM Middleware::Response ERROR: Object reference not set to an instance of an object.
 9/17/2019 11:22 AM Service Sleeping for 151 seconds

[Quazz]

@astrugatch That error is usually resolved by resetting encryption data from FOG Webui for the host/group

grep "put ip of client here" /var/log/apache2/access.log | tail for the access log thing

[Sebastian Roth]

@astrugatch said in See last time a computer checked into FOG:

9/17/2019 11:22 AM Middleware::Response ERROR: Unable to get subsection
9/17/2019 11:22 AM Middleware::Response ERROR: Object reference not set to an instance of an object.

Ok, so it tries to connect but fails due to an encryption error. Go to the FOG web UI -> host’s settings for this host and click the orange “Reset Encryption Data” button. If that doesn’t help you need to post more output from the logs here.

grep: access_log: No such file or directory

Sorry, my fault. See Quazz hint on the right command.

[astrugatch]

@Quazz

They’re not static so finding the IP would be a pain. I’m going to reset encryption data and see how that goes.

[astrugatch]

@Sebastian-Roth

After resetting encryption data all the modules seem to work except for User Tracker

------------------------------------------------------------------------------
----------------------------------UserTracker---------------------------------
------------------------------------------------------------------------------
 9/17/2019 3:06 PM Client-Info Client Version: 0.11.16
 9/17/2019 3:06 PM Client-Info Client OS:      Windows
 9/17/2019 3:06 PM Client-Info Server Version: 1.5.7
 9/17/2019 3:06 PM Middleware::Response Success
------------------------------------------------------------------------------

 9/17/2019 3:06 PM Service Sleeping for 142 seconds
 9/17/2019 3:09 PM Middleware::Communication URL: https://fog.spfk12.org/fog/management/index.php?sub=requestClientInfo&configure&newService&json
 9/17/2019 3:09 PM Middleware::Response Success
 9/17/2019 3:09 PM Middleware::Communication URL: https://fog.spfk12.org/fog/management/index.php?sub=requestClientInfo&mac=1C:4D:70:E4:56:98|1C:4D:70:E4:56:97|1C:4D:70:E4:56:9B||00:00:00:00:00:00:00:E0&newService&json
 9/17/2019 3:09 PM Middleware::Response Success
 9/17/2019 3:09 PM Middleware::Communication URL: https://fog.spfk12.org/fog/service/getversion.php?clientver&newService&json
 9/17/2019 3:09 PM Middleware::Communication URL: https://fog.spfk12.org/fog/service/getversion.php?newService&json

 9/17/2019 3:09 PM Service Creating user agent cache
 9/17/2019 3:09 PM Middleware::Response Module is disabled globally on the FOG server
 9/17/2019 3:09 PM Middleware::Response Module is disabled globally on the FOG server
 9/17/2019 3:09 PM Middleware::Response Module is disabled globally on the FOG server

Everything I see in the GUI says that it is enabled, Service settings on the client have it enabled, on the group it is a member of it is enabled, under service configuration its enabled, and under fog settings it is enabled

EDIT

Disregard all of that. The logins show up despite this output.

[Sebastian Roth]

@astrugatch said in See last time a computer checked into FOG:

----------------------------------UserTracker---------------------------------
------------------------------------------------------------------------------
 9/17/2019 3:06 PM Client-Info Client Version: 0.11.16
 9/17/2019 3:06 PM Client-Info Client OS:      Windows
 9/17/2019 3:06 PM Client-Info Server Version: 1.5.7
 9/17/2019 3:06 PM Middleware::Response Success
------------------------------------------------------------------------------

This is all perfectly fine - Response Success as you see.