Disappearing hosts from host list
-
sorry for ugly output, from phone it is hard
seems it has mac associated. what does pending means in this context?+------+----------+-------------------+--------+-----------+-----------+-------- --------+-----------------+ | hmID | hmHostID | hmMAC | hmDesc | hmPrimary | hmPending | hmIgnor eClient | hmIgnoreImaging | +------+----------+-------------------+--------+-----------+-----------+-------- --------+-----------------+ | 414 | 107 | 9c:5c:8e:93:ac:dc | | 0 | 0 | 0 | 0 | +------+----------+-------------------+--------+-----------+-----------+-------- --------+-----------------+ 1 row in set (0.00 sec) -
@Foglalt I fixed your ugly output.
-
Pending means the mac address has been registered, but is not “official” yet.
-
@george1421 thx for helping me out!
@Tom-Elliott and what does “not official” means?
Btw if zero means it is not pending, how can i get rid of this host? As it has mac, mac is not pending is it a legit host playing hide and seek somehow?
Anyway i see one interesting thing. the problematic host’s mac has no primary flag. Can it be the problem? if i modify that from 0 to 1 maybe it comes back to visible? (can it be done with database browser anyway, or is it “rape” of the database integrity? -
@Foglalt I just set all my MACs hmPending field to 0, everything is fine.
I need to see your problem myself. If you would message me via the forums messaging system, I can give you my email address and if you trust me enough, you can email me a copy of your database for me to look at. I should be able to very quickly figure out what’s wrong if I had a copy of your DB.
-
@Foglalt shared a copy of his DB with me, I have this figured out. It was related to the
hmPrimaryfield in thehostMACtable.FOG requires that each host have at least one MAC that is set to the primary. This host that is disappearing - for whatever reason - had a MAC associated to it that was not set as primary.
You can find all hosts that don’t have a primary MAC set with this command:
SELECT * FROM `hosts` WHERE `hostID` NOT IN (SELECT `hmHostID` FROM `hostMAC` WHERE `hmPrimary` = '1');And you can delete them with these commands:
DELETE FROM `hosts` WHERE `hostID` NOT IN (SELECT `hmHostID` FROM `hostMAC` WHERE `hmPrimary` = '1'); DELETE FROM `hostMAC` WHERE `hmhostID` NOT IN (SELECT `hostID` FROM `hosts`);I’ve updated the wiki with this maintenance command
Also - I don’t know how you got a clear-text password into the
hostADPassfield inside thehoststable - that shouldn’t even be possible. I’m suspecting someone did some manual work in the database and did that. -
@Wayne-Workman Pretty much, yep. That’s the only way they could’ve done it. (The plain text password in the hostADPass field.)
-
@Wayne-Workman thx for the work. About primary. Can it be checked somehow by code that a host with no primary mac cannot be save? I think i have a guess how it came.
That host field, the mac is normally updated when new cloning starts (we regularly do few hosts in pack as company now upgrades all pc “one by one”. I will check, but i think it is done as follows: new mac copied from hw library and pasted into for host record. Since now it has primary and other field, maybe colleague did it to other field, not the primary (he only deleted primary, then by mistake copied the new mac to nonpripary field.
If possible, pls dont let it be updated if no primary mac entry exists. Maybe it prevents this. I will ask him how he does, but i fear he wont remember the exact process, as it is dont in “half robot” mode (tons of pcs are repared, etc).
As for the hostADPass field. I forgot to ask it, but inspecting the problem i saw that, too. Is that field is for entering hosts to domain? I was not even aware that they use it. As far as i remember it is dont by scripting on the host, not by fog at all.
@Tom-Elliott No, none did any manual work about that password
Those who use fog for imaging, well, dont even care how it works. I will ask them, but i am totally sure they will be surprised even hearing it! (and shocked that password thing) -
Just for your intention: that strange user and password that was found in our database is even more strange. Those are actually fog users and passwords saved with host data. Fog client was never used in our environment and all (which would require ad passwords maybe).
Even more, user for ad cannot be saved from host or image gui part. None of my colleagues use any of db manipulating software (actually never ever used for any purpose
). This means that those fields are mysteriously got those info!This database was created with version 1.2.0, previous db was not used at all only as reference for the new database building (hosts are mass imported from newly created lists coming from other source).
So, if our database is corrupted somehow, we dont have no clue how it was done.
-
@Foglalt Is the original problem solved though? Were you able to register those disappeared hosts now?
If you want to dig into the DB issues, that should be another thread.
-
Sorry, i wasnot aware that I didnt press post on my reaction to this topic (pc left on when i went home and family killed memory fagments :D)
Yes, missing host issue was fixed. After that i could register that host again! THX for cooperation and kind help!
Anyway can i “mark it solved” somehow?
-
Guys, I know this topic is old, but i dont want to create a new topic as my issue now is the exact same as was in this topic. We here had solution to “fix database” with this issue, and i strongly hoped that the problem is only cos of some twisted database issue somehow, but now i again has it happening.
ATM, server is current uptodate 1.4.4, server os is debian 9.3, database is practically totally new (i kept only 2-3 image from old installation to make a new and flawless db. And colleagues report that host time-to-time disappeare from database.
As i has now key to find and eliminate it, i can solve this, but… god, it is so frustrating that i cant see the true reason for such. Issue is still same method as for creation: “dummy host” has mac, it gets deployed. new machine comes in, the original dummy is updated with new mac, deploying again. And on the mac update the host disappears sometimes! (mac is literally overwritten with new, which makes prev mac to be secondary or what? in host/mac pairing i see the new machine has the actual mac in db, but it has no primary mac. And as it has only 1 mac, it is “a host without mac” (as i cannot register a host without a mac, maybe gui wont display such hosts).
We previously cooperated in this matter, maybe with this post it can be continued towards a solution
I hope at least. -
@foglalt Are you sure it’s the same problem? Do the SQL commands I posted fix it still? I have some ideas on how to track down the issue.
-
@wayne-workman i am open for any idea. Issue is same on my end, i can fix it with previous methods you mention.
-
@foglalt Ok, give me a day or two - I’ll put together a monitoring script that will record when the problem occurs - the script will also grab the last 100 lines from apache access logs and error logs - and say the last 50 entries from the history table. That information will have the clues that we can use to find what’s causing this.
-
Ok, just take your time. I am glad that you guys are so responsive in all ways of user interaction! I dont even get the clue about that moron on forum claiming that fogproject is dead… We should thank your work, not complain in such nonsense way.
-
@foglalt I put together a script:
https://github.com/wayneworkman/fog-community-scripts/blob/master/troubleshootingTools/monitor-missing-primary-mac.sh
For future readers, this script will be here in the troubleshooting tools:
https://github.com/FOGProject/fog-community-scriptsIt monitors the count of hosts that are missing a primary mac. If the count goes above 0, it gets those host IDs, the last 100 lines of the apache access log, the last 100 lines of the apache error log, and the last 50 entires from FOG’s history table and dumps them to the file
/root/troubleshooting.log
Once that log file is written to, the script will not write anything else.Get the script onto your fog server, and then you will need to setup this script to run as a cron task every minute on your FOG Server. There’s lots of tutorials if you google search
cronorcrontabbut generally steps are as follows:sudo -i crontab -e # this might ask you if you want to use vim basic or vim tiny, it doesn't matter which. # Go into insert mode with: i # Paste in the below line: * * * * * /root/monitor-missing-primary-mac.sh # Or wherever you put the script. # Leave insert mode with the escape key esc # Save and close in vim with :wqThere are probably better tutorials out there on how to use Vim & create a cron job, but I put together this little Vim tutorial some years ago:
https://wiki.fogproject.org/wiki/index.php?title=ViIf you need further instructions/clarification on how to setup the script, just ask. When the file
/root/troubleshooting.logappears on your server, just look through it yourself first - remove any sensitive information. Maybe this file will help you figure out the bug yourself even. If not, you can share the file here with us and we can probably get a very good idea on how to reproduce this issue. -
And again, impressive response time! Thanks again
ok, i do preparation and wait fo the rabbit to jump out its nest. If i understand well, if a log appears it found something. Lets wait and hope. i will report back on next hit. (anyway you gave me good ideas on how to do some things for myself as i read through your script, nice work!) -
This post is deleted! -
@foglalt Do we have the rabbit yet?
