fix build & docker image

[anzz1]

fix build & docker image

• add hiredis
• fix configuration
• lower required cmake version 3.22 -> 3.5 to match docker image

[anzz1]

everything seems to work correctly now with the exception of peerchat
for some reason it always get stuck at this point https://github.com/chc/openspy-core-v2/blob/master/code/peerchat/server/Peer.cpp#L123-L126
user never get authenticated and get backend id so user's packets are ignored until registration timeout

[anzz1]

Okay the problem happens in https://github.com/chc/openspy-core-v2/blob/master/code/peerchat/tasks/Perform_SetUserDetails.cpp ,

If I add this log snippet:

        UserSummary userDetails = request.peer->GetUserDetails();
        bool nick_update = false;
        if(userDetails.id != 0) {
            response.summary.id = userDetails.id;
        } else {
            response.summary.id = GetPeerchatUserID(thread_data);
            nick_update = true;
        }
+        OS::LogText(OS::ELogLevel_Info, "[%s] Perform_SetUserDetails, nick: '%s', nick_original: '%s', id: %d, update: %d, req-summary: '%s', peer-summary: '%s'",
+         request.peer->getAddress().ToString().c_str(), formatted_name.c_str(), formatted_name_original.c_str(), response.summary.id, nick_update, request.summary.ToString().c_str(), userDetails.ToString().c_str());

        redisAppendCommand(thread_data->mp_redis_connection, "EXISTS usernick_%s", formatted_name.c_str());

This is returned in log:

peerchat_1        | [INFO]:GetPeerchatUserID: 0
peerchat_1        | [INFO]:[10.0.2.2:49802] Perform_SetUserDetails, nick: '', nick_original: '', id: 0, update: 1, req-summary: '[email protected]', peer-summary: '[email protected]'
peerchat_1        | [INFO]:[10.0.2.2:49802] OnGetBackendId, id: 0

So none of the fields seem to be set. Then it proceeds down to use the empty nick field in later redis commands, "EXISTS usernick_" , etc. Ultimately a key of "usernick_" with value: 0 gets created in the redis DB.

Other strange thing is that GetPeerchatUserID always returns 0, the INCR PEERCHATID command is sent successfully, the key "PEERCHATID" is created and incremented but whatever the current value is, the reply->integer is always 0.

I have no idea whether the problem is in the code or maybe some version incompatibility thing?

First of all, I did use hiredis v1.1.0 just assuming that's the correct one since your commit d3d6027 moving to hiredis was on 2023-07-10 which was the latest version then (hiredis v1.2.0 released two days later, deprecating TLSv1.1 and v1.0 support).

As far as openspy-core-v2 repo is concerned, all the other dependencies are properly versioned https://github.com/chc/openspy-core-v2/blob/master/Dockerfile so hiredis is the only thing which can be wrong version.

On the other hand, there is the openspy-web-backend repo. The C# .NET package dependencies for the main project are also properly versioned https://github.com/chc/openspy-web-backend/blob/master/openspy-web-backend/CoreWeb.csproj along with the build env https://github.com/chc/openspy-web-backend/blob/master/Dockerfile

However, in the docker-compose https://github.com/chc/openspy-web-backend/blob/master/docker-compose.yaml only the mysql image is versioned as mysql:5.7, rabbitmq uses a major build version of rabbitmq:3-management (don't know specifically about rabbitmq, but generally minor version increments can be presumed to potentially introduce breaking changes), and redis / mongo images don't have a specific version and thus are using the latest version which could definitely break things.

[anzz1]

Okay I finally figured it out, I was just looking in the wrong place, as it turns out it was a code problem rather than any compatibility thing. I suppose peerchat on production is running an earlier commit and not the latest from repo?

The problem was simply mismatching amounts of redisAppendCommand/redisGetReply in Perform_SetUserDetails. However fixing that leads to segfault on JOIN, so I guess the hiredis version of peerchat isn't quite complete yet? I'll probably have a look at all of this later along with some other fixes related to the message protocol (needed to ultimately fix anzz1/openspy-client#2).