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

[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.