[FOG 1.6] “Attempting to check in… Failed”

[jmeyer]

@Tom-Elliott

I have 290 host.
Delete host from GUI also bring the memory exhausted error.
What is strange is that import works fine.

I had to do this to run the test :

MariaDB [fog]> delete from hosts;
Query OK, 289 rows affected (0.155 sec)

I tried with only one host but I still can’t access the page.

[Sebastian Roth]

@jmeyer Would it be possible you share your CSV hosts (and maybe groups) export with us (private message to Tom and me)? This way we can try to replicate the issue.

[jmeyer]

@Sebastian-Roth Here are the 2 files :
Export Hosts FOG Project.csv
Export Groups FOG Project.csv

Maybe you also need installed apps version or a full db backup ?

After a week server was saying this and I had to force reboot.

[jmeyer]

@Sebastian-Roth
I have done this :

root@fogserver:/home/adminfog/fogproject# git checkout dev-branch
Extraction des fichiers: 100% (1029/1029), fait.
La branche 'dev-branch' est paramétrée pour suivre la branche distante 'dev-branch' depuis 'origin'.
Basculement sur la nouvelle branche 'dev-branch'
root@fogserver:/home/adminfog/fogproject# git pull
Déjà à jour.
root@fogserver:/home/adminfog/fogproject# git log -1
commit bf60833b45eb0f34452ded883b0eef87c6b2a0b1 (HEAD -> dev-branch, origin/dev-branch)
Author: Sebastian Roth <sebaroth@gmx.de>
Date:   Sun Mar 8 19:09:53 2020 +0100

    Prevent FOGMulticastManager from completing a task too early when the first host has checked out and fix typo in killTask function call
root@fogserver:/home/adminfog/fogproject# cd bin/
root@fogserver:/home/adminfog/fogproject/bin# ./installfog.sh

It has installed version 1.5.8.15 that is working fine.

[Sebastian Roth]

@jmeyer Switching between the two development versions dev-branch and working-1.6 is not recommended!! They are very different (not just the GUI but also in the database) and I am very sure you will run into issues sooner or later unless you have done a clean re-install of dev-branch.

Thanks for the CSV data. We will try to replicate the issue and see why it would cause memory exhaustion.

[jmeyer]

@Sebastian-Roth
Oops…
working-1.6 hasn’t the SQL fix and it fail during install.
And even if I end installing it, server looks to crash after a while.

What should I do ?

[Sebastian Roth]

@jmeyer Sorry, I just found the time to also add the SQL installer fixes to working-1.6 as well. I will work on trying to replicate the issue described here later on this week.

[jmeyer]

@Sebastian-Roth
I go back to working-1.6 and during install mysql process usage rise to 70%+ making server nearly not responding.

I have moved db to start a fresh one but I have the error message “Unable to update schema” when installing it.
I end only with this in db directory :

root@fogserver:/var/lib/mysql# ls fog -l
total 580
-rw-rw---- 1 mysql mysql    67 mars  13 17:07 db.opt
-rw-rw---- 1 mysql mysql 65536 mars  13 17:07 groupMembers.ibd
-rw-rw---- 1 mysql mysql 65536 mars  13 17:07 groups.ibd
-rw-rw---- 1 mysql mysql 65536 mars  13 17:07 history.ibd
-rw-rw---- 1 mysql mysql 65536 mars  13 17:07 hosts.ibd
-rw-rw---- 1 mysql mysql 65536 mars  13 17:07 images.ibd
-rw-rw---- 1 mysql mysql 65536 mars  13 17:07 schemaVersion.ibd
-rw-rw---- 1 mysql mysql 65536 mars  13 17:07 supportedOS.ibd
-rw-rw---- 1 mysql mysql 65536 mars  13 17:07 tasks.ibd
-rw-rw---- 1 mysql mysql 65536 mars  13 17:07 users.ibd

[Sebastian Roth]

@jmeyer said in [FOG 1.6] “Attempting to check in… Failed”:

I have moved db to start a fresh one but I have the error message “Unable to update schema” when installing it.

There should be more information in that error message when something goes wrong on shema update.

What Linux OS do you use?

I will work on this stuff on the weekend.

[Sebastian Roth]

@jmeyer I am not exactly sure what’s going on. I did a clean fresh install of FOG from working-1.6, schema update and importing your CSVs worked like a charm (though it took some seconds for both on my test VM).

I can capture and deploy images perfectly fine. Don’t see high CPU load or failed checkins on imaging tasks.

So my guess is that your hosts with fog-client installed are killing the webserver/PHP/DB thus causing you different issues.

Let’s try to work through this:

• Setup firewall rules to lock out most of the fog-client requests until we have it all back up:

sudo -i
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -s 10.121.84.13 -j ACCEPT
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

Make sure the IP address used is the one of the PC you work on.

• Connect to the database via command line client and drop the current FOG DB:

shell> mysql -u root -p
...
mysql> DROP DATABASE fog;
mysql quit

• Re-run the FOG installer on the console. Now this will ask you about disabling the firewall. Say no here so the rules from above stay in place!
• Now when you get to the schema update this time I would be fairly sure it’ll work right away.
• Login to the web UI -> FOG Configuration -> FOG Settings -> search for FOG_CLIENT_CHECKIN_TIME and increase that setting from 60 to 300 for now.
• I would expect the web UI to work just fine and don’t cause much load on the server. Go ahead and import your hosts and groups from CSV as well as create image definitions.
• As the last step we have to bring back the clients. I would start by adding iptables rules to allow for a few clients to connect at a time. Though this depends on how your network is structured and how many clients you have. So this is just an example of commands you will probably adjust to suite your situation:

iptables -A INPUT -p tcp --dport 80 -s 10.121.84.0/25 -j ACCEPT

• Allow for the fog-client software to talk to the server and pull the new longer checkin time set above (check fog.log in a couple of those machines). Then go for the next block of clients.

iptables -A INPUT -p tcp --dport 80 -s 10.121.84.128/25 -j ACCEPT

• And so on. You can allow for bigger blocks of clients using different address and netmask. It depends on your network. If this seems to be too much to go step by step there is another way. Just drop the iptables rules altogether and have all the fog-clients fire at your server at once again. It will take a while but should calm down by itself sooner or later.

iptables -P INPUT ACCEPT
iptables -F INPUT

[Sebastian Roth]

@jmeyer I am marking this solved as we have not heard back on this. Feel free to update this topic if you are still working on this and need help.