Now that is terrible news indeed...
In case anyone at GOG still gives a damn about anything (bar their bottom line and "growth"), could they somehow figure something out? :/

If it doesn't somehow affect Galaxy then they don't give a sh*t.

Maybe downgrade their SSL version back to the earlier one? Just joking.

I don't use magog so this is more like academic interest:

Do you mean it is not technically possible or feasible to do the upgrade on your end (e.g. one can't transfer all the existing data to the new system, it is somehow incompatible or whatever), or that you simply don't have time and interest for the task (of doing an upgrade to keep magog running and updating)?

Would the 2019 closure have come anyway, or is it solely due to this SSL version compatibility issue? Judging by earlier messages, it was already in some kind of "legacy mode", so...?

If there is enough interest and users with magog and the upgrade would be technically possible, would it be feasible for some interest user with enough skills to take it over? (Somehow I recall this was already asked before, or maybe it was some other GOG utility)?

Don't look at me though, not sure I had enough time (or expertise) for it, maybe I do, I don't know, but maybe someone who also uses the service...

I have no doubt it's technically possible. However, I use the same web server for several other projects, besides MaGog, not to mention it's my mail server. I'm just not willing to take the risk of all the problems that can surface up if I upgrade the OS, not to mention the downtime involved. I don't want to jeopardise the other projects, just because someone in GOG thinks that data that is completely public (e.g. their catalogue) needs to be super secure.

I wasn't planning to close it at all, but I don't see much point in continuing to keep it running now. with obsolete data. Legacy Mode was entirely useful, at least for me (since I will not buy any newer ("post legacy") GOG games anyhow), but Coma Mode is entirely useless.

I have no problem passing the code to someone else. I have already given it to Yepoleb for his GogDb project. I can give it to others too. That said, it was written for me, in my style and in Perl --- I suspect most others will find it rather difficult to get into.

RIP Magog, a great search engine. (T_T)
It was just a matter of time.

Btw I suggest its users to backup their info via:
- "Export My Data" button on Magog (linked to IDs)
- http://www.an-ovel.com/downloads/magog.txt (DB data)

That's a shame, completely understandable on your end though, it's not worth taking the risk of messing up your other projects and stuff to try and upgrade.

Have you considered mixing a touch of "been possible since the stone age" virtualization into things?

Assuming you're not super pressed for space, you could set up a chroot for MaGog and then upgrade only the OpenSSL for that chroot to ensure you don't jeopardize the rest of your projects.

I haven't used CentOS but, on Debian-family systems, there's a tool named "debootstrap" which makes it the work of one command to set up a base install of any requested Debian-based distro and release channel in a folder, which you can then chroot into and manipulate using that distro's package manager.

https://wiki.debian.org/Debootstrap

A quick search suggests that builds of debootstrap are available for CentOS (though I'm not sure which CentOS versions) and there appears to be an equivalent tool called supermin which began as febootstrap.

https://rwmj.wordpress.com/tag/febootstrap/

Absolute worst case scenario, you could spin up a copy of a Debian or Lubuntu live CD in a VM via VirtualBox's first run wizard, use debootstrap there, and then tar up the resulting folder with appropriate permissions- and ownership-preserving options and copy it over to your server.

I'm afraid that most of what you wrote went way over my head. I don't have any significant Linux experience beyond that of a basic user (ls, chmod, etc.). I didn't install my VPS web server; I have just been renting it for quite a few years now. It comes with an open-source control panel (kloxo), which is now end of life and no longer being maintained. And I figured out how to SSH as root to it in order to install some perl modules that didn't come with the server. That's about it.

If you can find a tutorial about how to do what you're suggesting from a bare-bones command line, I might try it.

UPDATE:

It looks like a solution has been found. Luckily for MaGog, the same issue that blocked her was also blocking the GOG downloader, and the solution that GOG has found for the downloader also solves MaGog's problem. I'm running a full update (2.5 hours) now to check, but so far so good.

... not even as preserve it as a part of GOG's history?


Anyway, though I didn't use it all that often, it's sad to see it go. But completely understandable.

Ah! That's good.

found this blog post here which provides an updated openssl that you can install as an additional package.
you still have to recompile whatever tool you use to gather the data from GOG against it (which may or may not bring additional problems).
but from what I saw CentOS 5 is past its 10 year support cycle and is not receiving any maintanance updates anymore. You probably want to look into updating your server anyway (or move your projects to a new server with a newer OS installed).
Running a public internet server with an outdated distro that is not recieving security updates is rather adventurous ;)

Nice, I thought it would be the same problem.

Just out of curiosity, did GOG fix it on their end or tell you of a work around?

On their end.
THANK YOU!!!
I'll look into it.

Adventurous is my middle name. My first name is Lazy.