Persistent Groups Not Working - FOG 1.5.9.235

[rodluz]

@Sebastian-Roth Thanks for the reply. I think you are right that it is an issue with PHP 8.

Yes please check the apache error log when this happens. See my signature on where to find the log.

I checked the apache error logs and there are no errors from trying to add the host to that group.

Is that one on PHP 8 as well? Please run dpkg -l | grep php-fpm on both servers and post the output here.

I ran the command on both systems and the server using FOG 1.5.94 is using PHP 7.2.24 while the new server with FOG 1.5.9.235 is using 8.1.

[Sebastian Roth]

@rodluz said in Persistent Groups Not Working - FOG 1.5.9.235:

I ran the command on both systems and the server using FOG 1.5.94 is using PHP 7.2.24 while the new server with FOG 1.5.9.235 is using 8.1.

This points to this being a PHP 8 issue. Though it’s strange you don’t see an error in the logs. I will try to replicate the issue as well. Will take a few days.

[Sebastian Roth]

Thanks to @Tom-Elliott for taking a look at this. So far it doesn’t look like a simple PHP (8) issue. We need to further dig into it. Will do a remote session with @rodluz.

[Sebastian Roth]

We have new information from @rodluz about different MySQL versions:

• Ubuntu 18.04.2 - FOG 1.5.9.94 - MySQL 5.7.39 - Plugin works
• Ubuntu 20.04.1 - FOG 1.5.9 - MySQL 10.3.34 - Plugin works
• Ubuntu 22.04.1 - FOG 1.5.9.235 - MySQL 10.6.11 - Plugin does not work

Could be a bug reported - though people on stackoverflow state they cannot replicate the issue as described - maybe interesting to give it a try.

Here I found another official bug report on triggers. But this seems to crash the DB and I don’t think we are running into that.

[Sebastian Roth]

@rodluz Good news. Found the time to look into this already and I might have it fixed as well. Before I commit the changes I would like to ask George to take a look as well as a sanity check. This is the first time I have played with this plugin and MySQL triggers in general…

I was able to get some more information on why it failed by trying to insert the group membership association by hand:

mysql> INSERT INTO `groupMembers` (`gmHostID`,`gmGroupID`) VALUES ('4','2') ON DUPLICATE KEY UPDATE `gmHostID`=VALUES(`gmHostID`),`gmGroupID`=VALUES(`gmGroupID`);
ERROR 1364 (HY000): Field 'paAnon5' doesn't have a default value

Proposed change on github: https://github.com/FOGProject/fogproject/pull/546/files (some comments added for clarification)

@george1421 May I ask you to comment on that?

Interestingly enough I am still not sure what change is caused the issue! Could be the MySQL version but I rather think it’s the change to InnoDB we made with FOG 1.5.9.133 (commit 7330fbc4).

I think it’s worth figuring out to make sure the proposed fix is not breaking other setups!! Anyone keen to figure that out?

[rodluz]

@Sebastian-Roth I just tested this change on my server and it is now working! Thank you

[Sebastian Roth]

@rodluz Thanks for testing and reporting back! I would still want to find out if this is caused by a change in the FOG code or the different MySQL version. Could you please do me a favor and update your Ubuntu 20.04.1 - FOG 1.5.9 - MySQL 10.3.34 setup to the latest dev-branch (which does not have the fix included yet)?

We’ll be waiting for George as well to comment on the pull request before merging it.

[george1421]

@Sebastian-Roth said in Persistent Groups Not Working - FOG 1.5.9.235:

Proposed change on github: https://github.com/FOGProject/fogproject/pull/546/files (some comments added for clarification)
@george1421 May I ask you to comment on that?
Interestingly enough I am still not sure what change is caused the issue! Could be the MySQL version but I rather think it’s the change to InnoDB we made with FOG 1.5.9.133 (commit 7330fbc4).

I can’t seem to think its FOG code at all. When I originally wrote this the whole action part of the script is done in mysql as a trigger. The FOG web site code doesn’t know this code exists, so to speak. You should be able to shutdown apache and manually insert a record into the host table and the trigger will fire. This makes me think its something on the mysql side. I’m not sure I understand the change requiring on duplicate key in that a key field should not have duplicates such as with a hostid or groupid. So this might point back to the FOG code doing something strange by trying to create two IDs with the same value.

From the structure of the edits in the patch it looks ok.

[Sebastian Roth]

@george1421 said in Persistent Groups Not Working - FOG 1.5.9.235:

When I originally wrote this the whole action part of the script is done in mysql as a trigger. The FOG web site code doesn’t know this code exists, so to speak.

Sure enough but my thinking was this could be a problem mit InnoDB only which we do use as default since some time. But could be MySQL version causing this too. I will find some time to test soon.

I’m not sure I understand the change requiring on duplicate key in that a key field should not have duplicates such as with a hostid or groupid.

In most cases this is not neccesary. But for example when I did several tests in a row (removed the host from the group and re-added the host the INSERT without ON DUPLICATE KEY UPDATE would fail because the location association already existed - as it’s not removed when a host leaves the group. With the ON DUPLICATE KEY UPDATE added it’s all good. Same for the other INSERTs!

From the structure of the edits in the patch it looks ok.

Ok, thanks! Merging the code then.

[Sebastian Roth]

@Sebastian-Roth said in Persistent Groups Not Working - FOG 1.5.9.235:

Could you please do me a favor and update your Ubuntu 20.04.1 - FOG 1.5.9 - MySQL 10.3.34 setup to the latest dev-branch (which does not have the fix included yet)?

Haha, that would not have triggered the issue because updating from 1.5.9 to dev-branch will not switch your DB table from MyISAM to InnoDB! Only new dev-branch installs are on InnoDB.

I did some extensive testing and it’s definitely the table engine InnoDB causing the initially reported problem. So it’s definitely good we got that fixed and from my tests there does not seem to be an issue with the new code, even on MyISAM tables. So I think we are good to go with this.