Host Cleanup
-
General question of curiosity. As most of work in school districts, we all know machines come and go frequently.
My question is, how do you all keep the host inventory of the FOG server, cleaned up, so there aren’t just a bunch of non exisit hosts taking up space?
With over 3000 devices (that will be in FOG) I am just trying to get a feel on how to keep old machines that have been scraped, out of the inventory.
-
@adukes40 I’ve not had to deal with this yet, as I’ve only been using fog for about 1.5 years to date.
As far as space goes - there’s no concern honestly. a host just takes up a row of text in the DB, it’s stored very eficiently and it will take perhaps two rows in the hostMAC table for it’s mac address.
I suppose if it came down to it, as long has you have the new client deployed, you could just delete all hosts and then the client will report in as pending in the web interface, then you’d just approve those as they show up.
I guess another way to know what’s gone is when you run a snapin for all computers. The ones that are gone will never run the tasks, so those tasks will sit around. You could click the hostnames in the tasks that linger, and delete those hosts - but be sure to give them lots of time to run - it’s totally possible that a computer could go for days or even weeks or months without being turned on in some cases.
-
@Wayne-Workman I don’t foresee space being an issue at all, just more so OCD kicking in. Starting fresh on something, just want to keep it clean as possible.
-
@adukes40 I’m just shooting an idea off the top of my head without actually looking into it. But if the target computers have the fog client on them, I wonder of FOG records the last check in time from the fog client. If it did you could create a report that might give clients that haven’t checked in, in the last 90, 180 or 270 days. That would tell you the systems that need to be reconciled.
-
@george1421 that would be a good way. We can do similar reports with our other software, if fog could do that kind of reporting that would be a path I would attempt.
-
Here is what I came up with. The userTracking table has what you need.
MariaDB [fog]> describe userTracking; +------------+--------------+------+-----+-------------------+----------------+ | Field | Type | Null | Key | Default | Extra | +------------+--------------+------+-----+-------------------+----------------+ | utID | int(11) | NO | PRI | NULL | auto_increment | | utHostID | int(11) | NO | MUL | NULL | | | utUserName | varchar(50) | NO | MUL | NULL | | | utAction | varchar(2) | NO | MUL | NULL | | | utDateTime | timestamp | NO | MUL | CURRENT_TIMESTAMP | | | utDesc | varchar(250) | NO | | NULL | | | utDate | date | NO | | NULL | | | utAnon3 | varchar(2) | NO | | NULL | | +------------+--------------+------+-----+-------------------+----------------+
This query will find the last time a user was tracked and what system ID was it. (I’m just being lazy because I could have joined back to the host table to pick up the actual name of the target system. )
select utHostID, max(utDateTime) from userTracking group by utHostID;
You will have to use an external report generator to make a nice report, but that query will do the job.
-
@george1421 I’ll give it a try. Dont need a fancy report, just a listing would suffice, I was going g to cross reference it with inventory to see if it has been relied, or trashed. Thanks George